Community
Participate
Working Groups
This is related to bug 352013 and bug 467142, but the problem appears to be more general: Many Egit operations cause the history view to change in several undesired ways. (a) the view port changes with no recognizable strategy, so the branches and commits I was working with are no longer visible. (b) Even after deselecting "Link with Editor and Selection" and not touching any filters, the history view filters for changes in the file of the current editor. It doesn't happen always on all commands, but I just reproduced it with a simple checkout command of a local branch. Also seen with pull & fetch from gerrit operations. I could imagine there's a connection between (a) and (b), because just now after check out the history was filtered such that the checked out commit was no longer in the list. Perhaps the history view was trying to scroll to this non-existent node. The result: it scrolled back thousands of commits taking me back into the year 2003. I have observed this problem for some years now (and reported bug 467142 6 years ago), just I could never really recognize a pattern when it happens, but it feels like 50% of all EGit operations. For every workflow involving more than one interaction with the history view this is a huge distraction. For (b) I have to select the repository in the "Switch Repository" tens of times every day. After that I still have to go hunting for the commits I had been looking at just a second ago. At least restricting history to just one file should *never* happen with user request, right? Maybe this gives a hint where in the code things go wrong?
Don't know what you mean by (a). But already (b) simply does not occur to me. When "Link with Editor and Selection" is off, the history view stays unchanged. Maybe a short screencast might help to better understand what exactly the problems you see in (a) are. Note that third-party plug-ins also have the possibility to trigger history page changes [1], but I would not expect those to occur when linking with editor/selection is off. Maybe it's also some Ref filters? I usually show all branches, ref filters HEAD ref/heads, refs/tags, and refs/remotes enabled, and "Show additional refs" also enabled. First parent only disabled. I _did_ have cases where I got really stupid behavior, but that was with the HEAD ref filter disabled. [1] https://wiki.eclipse.org/EGit/New_and_Noteworthy/5.7#API
OK, here's a little more information: I set breakpoints on all non-null assignments to HistoryPageInput.singleFile. When it fired I captured this stack (line numbers as of v5.9.0.202008260805-m3): BlameOperation$BlameHistoryPageInput(HistoryPageInput).<init>(Repository, IResource[]) line: 53 BlameOperation$BlameHistoryPageInput.<init>(Repository, RevCommit, IResource) line: 81 BlameOperation$RevisionSelectionHandler.selectionChanged(SelectionChangedEvent) line: 161 RevisionSelectionProvider.fireSelectionEvent() line: 193 RevisionSelectionProvider.setSelectedRevision(Revision) line: 182 RevisionSelectionProvider.access$1(RevisionSelectionProvider, Revision) line: 179 RevisionSelectionProvider$PostSelectionListener.selectionChanged(SelectionChangedEvent) line: 63 CompilationUnitEditor$AdaptedSourceViewer(TextViewer).firePostSelectionChanged(SelectionChangedEvent) line: 2638 CompilationUnitEditor$AdaptedSourceViewer(TextViewer).firePostSelectionChanged(int, int) line: 2585 TextViewer$2.run() line: 2564 Display.timerProc(long) line: 5774 GTK3.gtk_main_iteration_do(boolean) line: not available [native method] So blame annotations have a finger in the pie, and - yes - I use that feature a lot. Firstly, I would have expected that history-follows-selection only ever happens if "Link with Editor and Selection" is enabled, which I never do. Secondly, for the fun of it I verified that the following strategy creates weird results: 1. Open a file with recent changes. "Show Revision Information" and select a line that has been added recently. 2. For the fun of it switch to another editor without blame annotations shown 2.a optional: completely forget about the editor from step 1 :) 3. Ensure the history is focused on the repo not a single file 4. Check out a commit that doesn't contain the line selected in step 1. Ups: 4. History auto-selects the file from step 1 Whooops: 5. The hidden editor changes selection from the no longer existing line to line 1 6. History jumps to the commit where that commit was last modified (line 1 typically has a last change many years in the past, likely file creation date). I see several bugs: * it reacts to selection changes even if that feature is not enabled * it limits the history to a single file without the user requesting so in any way * it reacts to selection changes in a hidden editor * it reacts to selection changes not performed by the user The last issue may be hard/impossible to detect by EGit, but all others seem to be withing the realm of EGit.
Did anybody ever succeed to reproduce? This is interfering with some of my most frequent workflows every day.
The constant pain for me is that after deleting a temporary branch that was used to push something to gerrit, History view jumps to some commit in the middle of the project history, even if the master branch was already shown and visible, so I have to scroll like a hell back to the top. I've just tried that and I couldn't reproduce with a dummy branch, but I constantly see that behavior of unmotivated jumping back years of the history.
(In reply to Andrey Loskutov from comment #4) > The constant pain for me is that after deleting a temporary branch that was > used to push something to gerrit, History view jumps to some commit in the > middle of the project history, even if the master branch was already shown > and visible, so I have to scroll like a hell back to the top. I've just > tried that and I couldn't reproduce with a dummy branch, but I constantly > see that behavior of unmotivated jumping back years of the history. Did you see my observation regarding blame annotations (comment 2)? For me this scenario can be reliable reproduced.
No, I had no editor with blame annotations opened. I've just saw this by creating a new branch on top of master, "single" branch mode in History view, HEAD at "master" is selected, editor from same repo is opened. Right click in History on HEAD -> Create branch -> check all boxes -> after creating the branch, History view jumped down to some unrelated commit, I had to scroll back to the top. Trying to reproduce exact steps immediately after that, just with another branch name didn't reproduce the problem.
Let's go back to the original report: (In reply to Stephan Herrmann from comment #2) > Secondly, for the fun of it I verified that the following strategy creates > weird results: > > 1. Open a file with recent changes. "Show Revision Information" and select a > line that has been added recently. > 2. For the fun of it switch to another editor without blame annotations shown > 2.a optional: completely forget about the editor from step 1 :) > 3. Ensure the history is focused on the repo not a single file > 4. Check out a commit that doesn't contain the line selected in step 1. > > Ups: > 4. History auto-selects the file from step 1 Cannot reproduce (on EGit nightly). > Whooops: > 5. The hidden editor changes selection from the no longer existing line to > line 1 Cannot reproduce. > 6. History jumps to the commit where that commit was last modified (line 1 > typically has a last change many years in the past, likely file creation > date). Cannot reproduce. What I *do* see is that someone thought it clever to navigate in the history when the text selection in the editor (with revisions shown) moves from a text area belonging to one revision to an area belonging to the next revision. > I see several bugs: > * it reacts to selection changes even if that feature is not enabled Yes, bug. Two possible solutions: do it only if the history view is set to follow the selection, or don't do it at all. The latter is IMO also an option; if the user wants to show a commit in the history, he or she can hover over the revision on the left and click the "Show in history" link in the pop-up. > * it limits the history to a single file without the user requesting so in > any way Linked to the above point. I'd argue for people who want this, it makes sense to focus on the file the blame annotations are for. > * it reacts to selection changes in a hidden editor Cannot reproduce. > * it reacts to selection changes not performed by the user Cannot reproduce. Seems to me that solving "it reacts to selection changes even if that feature is not enabled" would solve this bug.
New Gerrit change created: https://git.eclipse.org/r/c/egit/egit/+/183257
Gerrit change https://git.eclipse.org/r/c/egit/egit/+/183257 was merged to [master]. Commit: http://git.eclipse.org/c/egit/egit.git/commit/?id=5d96c25498ea401cd3482dc8c346f748cbceed3c
(In reply to Eclipse Genie from comment #9) > Gerrit change https://git.eclipse.org/r/c/egit/egit/+/183257 was merged to > [master]. This makes blame update the history only if "Link with Editor and Selection" is enabled in the history view. @Stephan, does this solve the problems you had?
(In reply to Thomas Wolf from comment #10) > (In reply to Eclipse Genie from comment #9) > > Gerrit change https://git.eclipse.org/r/c/egit/egit/+/183257 was merged to > > [master]. > > This makes blame update the history only if "Link with Editor and Selection" > is enabled in the history view. > > @Stephan, does this solve the problems you had? Using Eclipse EGit 5.13.0.202107262044 indeed unsolicited jumping in the history no longer occurs. Thanks.
*** Bug 467142 has been marked as a duplicate of this bug. ***
