Community
Participate
Working Groups
When selecting a branch in the repository view and invoking "Show in History" I could not figure out any useful effect. Hence the question: what is this function supposed to do? I had expected that the tip of the selected branch would be focused, perhaps selected in the history view. But regardless whether I select a local branch or a remote tracking branch, the history view doesn't seem to change. Wait: the detail part of the view does change: showing the commit at the tip of the branch, but where is the branch?? This is somewhat the opposite of bug 572886: in the other bug the history view jumps in undesired ways. In this bug it does not jump when desired.
Do you have the history view filtered to show only particular branches? Or is it set to show them all? If the commit at the tip of the branch is currently filtered out of the history view, it won't be shown.
Created attachment 286807 [details] filter options (In reply to Thomas Wolf from comment #1) > Do you have the history view filtered to show only particular branches? Or > is it set to show them all? If the commit at the tip of the branch is > currently filtered out of the history view, it won't be shown. not filtered
Strange. Works for me. When the history view is set to follow the selection the commit selected is just below the visible table area though (i.e, scroll down one item, then it appears).
(In reply to Thomas Wolf from comment #3) > Strange. Works for me. When the history view is set to follow the selection > the commit selected is just below the visible table area though (i.e, scroll > down one item, then it appears). I decidedly don't want "follow selection", because I want to avoid any unintended jumping (trying to get rid of bug 572886 like behavior). More observations: (1) yes: cursor up/down *may* help to get the desired commit into the view port, but for me it's not "just below the visible table area", because "Show in History" doesn't move the view port at all. (2) For the scroll trick to work you must explicitly set focus to the history graph before invoking "Show in History". It's not focused by default, and if previously you selected a detail pane, it will only scroll in that pane so not helpful for getting a commit into focus. Still the explicit scroll should never be necessary, right? :) Actually this works *sometimes*: [x] Link with Editor and Selection Single-click on a branch in the repository view (i.e, not using "Show in History") When it fails this seems to be the symptom you are describing (one off). Still this bug is about "Show in History" without "Link with Editor and Selection".
(In reply to Stephan Herrmann from comment #4) > Still the explicit scroll should never be necessary, right? :) It shouldn't. Found that "off by one", but have to test the fix a little more. > Actually this works *sometimes*: > [x] Link with Editor and Selection > Single-click on a branch in the repository view (i.e, not using "Show in > History") > > When it fails this seems to be the symptom you are describing (one off). > > Still this bug is about "Show in History" without "Link with Editor and > Selection". Works mostly for me. Just noticed if I switch off the "Find" toolbar item there is a problem. With the Find toolbar item off the history view loads history incrementally, and then sometimes "Show in History" indeed doesn't do anything if I select a branch pointing at very old commit that doesn't get loaded initially.
New Gerrit change created: https://git.eclipse.org/r/c/egit/egit/+/183251
(In reply to Eclipse Genie from comment #6) > New Gerrit change created: https://git.eclipse.org/r/c/egit/egit/+/183251 That should fix the "off by one".
New Gerrit change created: https://git.eclipse.org/r/c/egit/egit/+/183345
Gerrit change https://git.eclipse.org/r/c/egit/egit/+/183251 was merged to [master]. Commit: http://git.eclipse.org/c/egit/egit.git/commit/?id=ac7639fe7700e4f7e4e23bd2ccc3f7be13cba583
Gerrit change https://git.eclipse.org/r/c/egit/egit/+/183345 was merged to [master]. Commit: http://git.eclipse.org/c/egit/egit.git/commit/?id=576846473851b0d431b261cebbf7dc6e9b6ad5b3
(In reply to Eclipse Genie from comment #10) > Gerrit change https://git.eclipse.org/r/c/egit/egit/+/183345 was merged to > [master]. This fixes a problem with showing old branches, where the target commit is not within the first n commits, n being determined by the preference "Maximum number of commits to show" in the Git->History preferences. @Stephan, please give EGit nightly a try.
Using EGit 5.13.0.202107262044 Show in History (from branch in repository view) works fine. But I noticed that after invocation, the next time the context menu is much truncated to only show: - Check Out - Create Branch - Create Tag - Show in > <No Applicable Views> I have to click to another view and then back into the repository view to get the complete context menu back. Is this caused by loss of focus / selection in the Repository view? Note, that in this case the History View was detached on my second monitor. Things work fine, when all views are shown in the same window. Should I file a new bug for this?
(In reply to Stephan Herrmann from comment #12) > Using EGit 5.13.0.202107262044 Show in History (from branch in repository > view) works fine. > > But I noticed that after invocation, the next time the context menu is much > truncated to only show: > > - Check Out > - Create Branch > - Create Tag > - Show in > <No Applicable Views> > > I have to click to another view and then back into the repository view to > get the complete context menu back. Is this caused by loss of focus / > selection in the Repository view? > > Note, that in this case the History View was detached on my second monitor. > Things work fine, when all views are shown in the same window. > > Should I file a new bug for this? Yes, that sounds like something else. First, does this occur only when the detached history view is on the secondary monitor, or also when it is on the same monitor? The latter would be much easier for me to test; I have only one single monitor. :-) Second, yes, my initial suspicion is that the right click on the repo view opens the context menu without setting focus to the repo view. So the current selection is off. That may well be an OS-dependent problem in Eclipse platform; I don't see it on OS X. We had a similar problem in the file list bottom right in the history view, where we could fix it by explicitly setting focus when the menu was created. (Bug 477510.) Would be interesting to know what happens on Linux on a "direct right click" on the package explorer (i.e., focus on some other top-level shell, move mouse pointer over some file in the package explorer in non-active shell, right click): what does the "Show In" sub-menu show there? If it is such a "right click does not focus" problem it's probably a bug in Eclipse platform on Linux, and it's not certain EGit can work around it.
(In reply to Thomas Wolf from comment #13) > First, does this occur only when the detached history view is on the > secondary monitor, or also when it is on the same monitor? The latter would > be much easier for me to test; I have only one single monitor. :-) Detached on the same monitor has the same effect. > Second, yes, my initial suspicion is that the right click on the repo view > opens the context menu without setting focus to the repo view. So the > current selection is off. Playing around more, I don't see it as lack of settings focus on right click, but a matter of activating a window: To "fix" the context menu it suffices to activate the window holding the repository view, then come back to the main window. Just a right click will be enough to get the full context menu. > That may well be an OS-dependent problem in Eclipse platform; I don't see it > on OS X. We had a similar problem in the file list bottom right in the > history view, where we could fix it by explicitly setting focus when the > menu was created. (Bug 477510.) Would be interesting to know what happens on > Linux on a "direct right click" on the package explorer (i.e., focus on some > other top-level shell, move mouse pointer over some file in the package > explorer in non-active shell, right click): what does the "Show In" sub-menu > show there? On my desktop (where focus policy is "Focus follows Mouse") there is no state where window B is active and right-click occurs in window A. Quite likely the platform and the focus policy has a finger in the pie. Now that I know a workaround, this is of little relevance for me :)
