Community
Participate
Working Groups
Eclipse EGit 1.2.0.201111160714 Eclipse SDK 4.2.0.I20111116-0810 Perhaps related to Bug 358020. I had a case yesterday where I was selecting a (git) file in the Package Explorer and doing a Compare With -> Branch, Tag or Reference. I would choose a tag to compare with but when the compare view opened, the compare was being done on a different file altogether. I tried it multiple times but it consistently compared against the same wrong file. I talked to John and he pointed out the path was incorrect in the top of the compare dialog and mentioned there was a perhaps related problem recently fixed (Bug 358020) in and around selection changes in views. I don't have reproducible steps yet but I had been using the Commit view, History view, and others.
DJ, if this happens to you again, try 'Window > New Window' and see if the problem occurs in the new window. Thanks.
Just encountered this while trying 'Compare with HEAD'...truly strange since it ended up comparing the UIElement.ecore file which I haven't even had open for weeks... BTW, I did a Window -> New Window and it seems to be sane again (this is still scarey, 3.x users who encounter this will question the stability of 4.x in general IMO).
Remy, where abouts are their compare with actions/handlers? PW
(In reply to comment #3) > Remy, where abouts are their compare with actions/handlers? Knock yourself out. http://egit.eclipse.org/w/?p=egit.git;a=tree;f=org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/actions;hb=HEAD
Just got hit by this bug with I20111124-2200 on Windows 7.
1. Make a new untracked file. 2. Open the 'Git Staging' view. 3. Select the file > Context menu > Replace with File in Git Index. 4. Nothing happens. I would argue this is a bug in EGit. 5. Go try and use 'Compare With' on another file now. The selection has now been locked.
getActiveMenuSelection(*) returns the old selection. getCurrentSelectionChecked(*) returns the correct selection.
Fix released to master. Thanks for the bug report, DJ. http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=ad263d22eba32dcd7eb2b1b2cf4b6450f9769abb Trace of EGit calling getCurrentState(). Thread [main] (Suspended (breakpoint at line 556 in LegacyHandlerService)) LegacyHandlerService.getCurrentState() line: 556 StagingView.createItem(String, TableViewer) line: 898 StagingView.access$23(StagingView, String, TableViewer) line: 889 StagingView$21.menuAboutToShow(IMenuManager) line: 850 MenuManager.fireAboutToShow(IMenuManager) line: 342 MenuManager.handleAboutToShow() line: 473 MenuManager.access$1(MenuManager) line: 469 MenuManager$2.menuShown(MenuEvent) line: 495 TypedListener.handleEvent(Event) line: 247 EventTable.sendEvent(Event) line: 84 Menu(Widget).sendEvent(Event) line: 1053 Menu(Widget).sendEvent(int, Event, boolean) line: 1077 Menu(Widget).sendEvent(int) line: 1058 Shell(Control).WM_INITMENUPOPUP(long, long) line: 4881 Shell(Control).windowProc(long, int, long, long) line: 4557 Shell(Canvas).windowProc(long, int, long, long) line: 341 Shell(Decorations).windowProc(long, int, long, long) line: 1627 Shell.windowProc(long, int, long, long) line: 2069 Display.windowProc(long, long, long, long) line: 4972 OS.TrackPopupMenu(long, int, int, int, int, long, RECT) line: not available [native method] Menu._setVisible(boolean) line: 256 Display.runPopups() line: 4206 Display.readAndDispatch() line: 3748 PartRenderingEngine$9.run() line: 977
I had a look at the code for org.eclipse.egit.ui.internal.staging.StagingView.createItem(String, TableViewer) They're just setting a variable into the context and hoping that will be the correct thing when a user executes their view. They have a race condition with any other SWT events that might change the selection, although it probably works ... mostly. PW
(In reply to comment #6) > 1. Make a new untracked file. > 2. Open the 'Git Staging' view. > 3. Select the file > Context menu > Replace with File in Git Index. > 4. Nothing happens. I would argue this is a bug in EGit. > 5. Go try and use 'Compare With' on another file now. The selection has now > been locked. The incorrect behaviour cannot be reproduced and the 'Git Staging' view appears to continue to function properly with I20111205-2330 on Windows 7. DJ, let me know if you see this again.
