Community
Participate
Working Groups
If I right click on a file and choose "Replace With > Previous Revision" it would be useful if this would show the commit message. e.g. Replace With > Previous Revision (Fix Bug 12345 ...)
Perhaps that would be useful, but it's also a sure way to kill UI performance. Getting the commit message of a commit is an operation that will access the on-disk files of the repository (underneath .git). We must avoid doing that when the menu is to be shown; otherwise it may suddenly take a long time until the menu comes up. Another problem then would be: which commit message to show? The one of HEAD~1, or the one of the commit that last touched the file? The latter would take even longer. And then, assuming we used HEAD~1 and had figured a clever to pre-load the message and cache it (and know when to invalidate that cache!), we'd run into bug 540778/bug 315619 on Windows.
(In reply to Thomas Wolf from comment #1) > Perhaps that would be useful, but it's also a sure way to kill UI > performance. Currently I have the History view open to show me the revision information that *seems* quite fast ... > Getting the commit message of a commit is an operation that will access the > on-disk files of the repository (underneath .git). We must avoid doing that > when the menu is to be shown; otherwise it may suddenly take a long time > until the menu comes up. Maybe this could be fetched in the background (not sure how the History view works) and then the menu item updated? > Another problem then would be: which commit message to show? The one of > HEAD~1, or the one of the commit that last touched the file? I think the one the file would be replaced with. > The latter would take even longer. Any idea how "long" longer is? As mentioned above I found the History View quite fast and it show a lot more information (even when selecting single files). > And then, assuming we used HEAD~1 and had figured a clever to pre-load the > message and cache it (and know when to invalidate that cache!), we'd run > into bug 540778/bug 315619 on Windows. For Bug 540778 / Bug 315619 one might show only up to 20 characters or someone could be triggered to ix those bugs :-)
(In reply to Christoph Laeubrich from comment #2) > (In reply to Thomas Wolf from comment #1) > > Perhaps that would be useful, but it's also a sure way to kill UI > > performance. > > Currently I have the History view open to show me the revision information > that *seems* quite fast ... The history view is something else. It's a view, it can spawn jobs, compute things in the background, and update asynchronously. You can't do that when opening a context menu. And it's still slow. The UI is responsive, but it takes too long until a history has been loaded or the table starts updating. > > Getting the commit message of a commit is an operation that will access the > > on-disk files of the repository (underneath .git). We must avoid doing that > > when the menu is to be shown; otherwise it may suddenly take a long time > > until the menu comes up. > > Maybe this could be fetched in the background (not sure how the History view > works) and then the menu item updated? Unlikely to be helpful. Most likely the user has already chosen a menu entry and executed the command by the time that background computation is done. > > Another problem then would be: which commit message to show? The one of > > HEAD~1, or the one of the commit that last touched the file? > > I think the one the file would be replaced with. That is always going to be HEAD~1. A commit always has the full tree. Showing the commit message from HEAD~1 is not very useful, though. I at least rarely loose my head. I also don't really care about which commit it comes from. When I use this operation, I just want to undo whatever changes I made in my current commit. > > The latter would take even longer. > > Any idea how "long" longer is? As mentioned above I found the History View > quite fast and it show a lot more information (even when selecting single > files). "long" is too long for a context menu. You can't go walk a commit history to determine a menu label. Imagine a file last touched a few hundred or thousand commits back. Moreover, since that commit may be different depending on the file(s) selected, that commit message cannot be cached.
BTW: even looking for the right commit in the UI thread once the operation is executed can already take too long, see bug 463229.
In fact, there is another place where the performance impact can be seen already. The replace with menu in the staging view shows the 2 alternatives when the repo has a merge conflict, similar to what you request right now. We already did some fixes to improve the performance there, but opening the context menu still blocks on some of my larger repos for seconds. That's not something you want in the project explorer.
