Community
Participate
Working Groups
Saving changes in the compare editor doesn't work if the swap sides preference is activated (i.e. "Swap left and right view"). If the compare editor is closed without saving it asks for saving but it is not saved if "Yes" is selected. Also Strg+S doesn't save the performed changes. Saving works without problems if swapping is disabled (i.e. "Swap left and right view" is not selected). -- Configuration Details -- Product: Eclipse 4.6.2.20161208-0625 (org.eclipse.epp.package.cpp.product)Installed Features: org.eclipse.platform 4.6.2.v20161124-1529
Can you please provide exact steps to reproduce? I've tried this right now with 4.6.3 RC3 and it works fine for me if I (with .properties or .java files): 1) Change local file - add a comment 2) Git Compare with -> Head 3) In the compare editor, on the right (local) side, add another comment 4) Save via "Ctrl+S"
I'm using the Subclipse plugin. 1) Compare With -> Base Revision 2) Use the button "Copy current change from Left to Right" 3) Save via "Ctrl+S" 4) Close the compare editor 5) Open file which was changed -> Still the old content, changes not saved
(In reply to Sebastian Priebe from comment #2) > I'm using the Subclipse plugin. > > 1) Compare With -> Base Revision > 2) Use the button "Copy current change from Left to Right" > 3) Save via "Ctrl+S" > 4) Close the compare editor > 5) Open file which was changed -> Still the old content, changes not saved A-ha. It works with egit and local history too. Can you please try if you can simply edit a local file, and see same behavior if you do "compare with local history" and then same steps as above? Probably the problem is in subclipse?
For me it also doesn't work with local history. If I have the local file opened and I hit Ctrl+S in the compare editor the file gets marked dirty (with a *) but it is not saved. The same if the file isn't open. If I open it after hitting Ctrl+S in the compare editor it is marked dirty, too. Please note: I'm working with version 4.6.2 with the CDT stuff.
I just tried CDT 4.6.3 RC2 with the same results for Subclipse but it works with the local history.
(In reply to Sebastian Priebe from comment #5) > I just tried CDT 4.6.3 RC2 with the same results for Subclipse but it works > with the local history. Thanks, I will close this one as "not Eclipse". I can't reproduce with the tooling coming from eclipse.org, so most likely you should open a ticket at subclipse for investigation. If it turns out, the problem is in Eclipse code, please feel free to reopen this ticket but please provide detailed explanation why do you think the problem is in Eclipse.org code.
I think there still might be an issue here. We are extending CompareEditorInput and then using CompareUI.openCompareEditor(compareInput) to open the compare/merge editor. If we set the right side editable but then either the "Swap left and right view" button is used in the compare/merge editor or the corresponding preference is enabled, when making a change and requesting a save, ContentMergeViewer.flushLeftSide() is checking getCompareConfiguration().isLeftEditable() to see if the left side is editable - this is false as was defined in the initial CompareConfiguration so the changes are NOT saved. It seems like ContentMergeViewer should be using its own isLeftEditable() method to check whether the left side is editable - this method checks CompareConfiguration.isMirrored() and checks the configuration's left/right side for editable accordingly. Let me know if I'm wrong on this as I'm just not seeing how/where to handle the swap/mirror preference change if part of this is up to the user of these classes.
Tim, can you provide steps to reproduce, or example plugin? Do you want to contribute a fix? See https://wiki.eclipse.org/Platform_UI/How_to_Contribute.
(In reply to Andrey Loskutov from comment #8) > Tim, can you provide steps to reproduce, or example plugin? Do you want to > contribute a fix? See https://wiki.eclipse.org/Platform_UI/How_to_Contribute. Yes, I should hopefully be able to carve out some time this week to provide a simple example to reproduce the bug and a suggested fix. Thanks, Tim
(In reply to Tim Kosacek from comment #9) > Yes, I should hopefully be able to carve out some time this week to provide > a simple example to reproduce the bug and a suggested fix. This would be great. BTW, I believe I've seen this in the EGit compare editor if comparing index with head, edits are not persisted if the sides are swapped (or working copy with index?). @EGit team: have you observed this too, is this known issue?
(In reply to Andrey Loskutov from comment #10) > @EGit team: have you observed this too, is this known issue? I have not observed this, but then I basically never use this side switching. AFAIK there is no bug report in EGit relating to this. Just gave it try, and I cannot reproduce this with EGit.
OK, looks like I've got this now: 1) add two lines to text file in two different places so that we have two text diffs 2) stage the file and open diff from the staging view by double clicking staged file 3) Make sure "Swap left and right" has toggled (pressed) state, so the new lines are on the right side 4) Place cursor on the first diff and click on "Copy current change from left to right". This should undo the change in index. 5) Save the "dirty" diff via Ctrl+S. This *should* undo the change on the index and refresh the view so that we see a change in the working tree - but nothing changes at all (except the diff shows us no change in index). Commit now this change. 6) In the git history we see that both lines are committed. If "Swap left and right" is NOT toggled, in step 5 we commit only one line, and working tree shows another change in the unstaged area.
(In reply to Andrey Loskutov from comment #12) > OK, looks like I've got this now: > > 1) add two lines to text file in two different places so that we have two > text diffs > 2) stage the file and open diff from the staging view by double clicking > staged file > 3) Make sure "Swap left and right" has toggled (pressed) state, so the new > lines are on the right side > 4) Place cursor on the first diff and click on "Copy current change from > left to right". This should undo the change in index. > 5) Save the "dirty" diff via Ctrl+S. > This *should* undo the change on the index and refresh the view so that we > see a change in the working tree - but nothing changes at all (except the > diff shows us no change in index). Commit now this change. > 6) In the git history we see that both lines are committed. > > If "Swap left and right" is NOT toggled, in step 5 we commit only one line, > and working tree shows another change in the unstaged area. This appears to be fixed with the fix for bug 522245. I can reproduce it with EGit nightly 5.3.0.201901061808, but EGit nightly 5.3.0.201901121419 works as expected. The difference between these two EGit nightly versions are exactly the change done for bug 522245 plus a clean-up: https://git.eclipse.org/r/#/c/134955/ and https://git.eclipse.org/r/#/c/134956/ .
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
