Community
Participate
Working Groups
I compare a change in the 'Git Staging' view and after I undo some changes by copying a change from right to left and save, no diff recalculation is performed so the compare editor still think there is a change around those lines in the file. The CVS compare doesn't seem to have this problem.
In CVS, but it's also true for local files, when save is made SavebaleHelper calls doSaveModel[1] for each saveable[2] in the editor. In most cases, it's a single iteration because the Compare Editor has been opened for SaveableCompareEditorInput[3], which has only left side can be edited (saved). I don't know what kind of input EGit uses for their Compare Editor. I would start from finding that out. [1] org.eclipse.ui.internal.SaveableHelper.doSaveModel(Saveable, IProgressMonitor, IShellProvider, boolean) [2] org.eclipse.ui.Saveable [3] org.eclipse.team.ui.synchronize.SaveableCompareEditorInput
Thank you for your research, Tomasz! The problem seems to be because GitCompareFileRevisionEditorInput does not have an implementation for the abstract fireInputChange() method. If I force the compare result to fire a change like what it's doing in CompareFileRevisionEditorInput then it works. Tomasz, is this the expected pattern? That we subclass DiffNode and then provide a public version of fireChange() to invoke within fireInputChange()? You can find our implementation of prepareCompareInput(IProgressMonitor) below: http://egit.eclipse.org/w/?p=egit.git;a=blob;f=org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/GitCompareFileRevisionEditorInput.java;h=f3c23097ad167b5d8ee6e03f5d66d972a97144b0;hb=HEAD
(In reply to comment #2) > Tomasz, is this the expected > pattern? That we subclass DiffNode and then provide a public version of > fireChange() to invoke within fireInputChange()? From what I can see looking at implementations of SaveableCompareEditorInput in Team, it seems to be right approach. All those inputs have a meaningful implementation of the #fireInputChange method. However, if you take a look at comment for org.eclipse.team.ui.synchronize.SyncInfoCompareInput.MyDiffNode you will read "This class exists so that we can force the text merge viewers to update by calling #fireChange when we save the compare input to disk. The side effect is that the compare viewers will be updated to reflect the new changes that have been made. Compare doesn't do this by default.". So, to me, it sounds like an optional thing. Not sure if this answers your question.
*** Bug 353537 has been marked as a duplicate of this bug. ***
A change set has been attached to Gerrit for review. http://egit.eclipse.org/r/#change,4073
merged as http://egit.eclipse.org/w/?p=egit.git;a=commit;h=c9eda1b41e5dff5048bba57f82010b2f715915c3