Community
Participate
Working Groups
Clicking "Cancel" or "OK" has the same effect in the Stash dialog being opened in the history view via "Modify->Stash". In both cases the commits are stashed. That should only happen if one clicks on OK but not in the case one clicks on Cancel.
There is no Modify > Stash menu item. Do you mean the dialog that is shown when clicking Modify > Edit and there are uncommitted changes? If not, please explain the exact steps to reproduce. With the above, I could reproduce a problem in that clicking cancel there would still open other views, proposed fix: https://git.eclipse.org/r/36880
(In reply to Robin Stocker from comment #1) > There is no Modify > Stash menu item. Do you mean the dialog that is shown > when clicking Modify > Edit and there are uncommitted changes? If not, > please explain the exact steps to reproduce. > > With the above, I could reproduce a problem in that clicking cancel there > would still open other views, proposed fix: > > https://git.eclipse.org/r/36880 merged as 48fd04618e1866775186cbf29bfc55b7c3bdcf10
Created attachment 248842 [details] Screenshot of Squash Context Menu Let me explain more in detail: The attached screenshot shows the context menu I am referring to. The problem really is the dialog which opens after clicking on Stash allows you to modify the commit message. That one allows to edit the commit messages. Clicking on Cancel here will not cancel the squash operation but will just take the default commit message. So at that point in time I am not able to cancel the operation with the GUI. That is not really expected from a user's point of view. I would prefer if the dialog for editing the commit message would allow to cancel the actual squash operation.
I stumble over this today. Clicking cancel or hitting Esc wont cancel squash operation and the default commit message will be applied. # This is a combination of 2 commits. # The first commit's message is: ... <- first commit msg # This is the 2nd commit message: ... <- second commit msg Tested with Egit version is 4.2.0
*** Bug 488447 has been marked as a duplicate of this bug. ***
Just bumped into this in 4.9.1.
Bumped into this today. The wording of the cancel button is confusing here, as the dialog is just there to change the commit message. Maybe changing the "Cancel" label to something like "Keep message" or "Skip" would reduce confusion?
(In reply to Simon Muschel from comment #7) > Bumped into this today. The wording of the cancel button is confusing here, > as the dialog is just there to change the commit message. Maybe changing the > "Cancel" label to something like "Keep message" or "Skip" would reduce > confusion? yes
New Gerrit change created: https://git.eclipse.org/r/154799
Gerrit change https://git.eclipse.org/r/154799 was merged to [master]. Commit: http://git.eclipse.org/c/egit/egit.git/commit/?id=d2d3cada1c56973e27829990e5d87425469ead9f
(In reply to Eclipse Genie from comment #10) > Gerrit change https://git.eclipse.org/r/154799 was merged to [master]. > Commit: > http://git.eclipse.org/c/egit/egit.git/commit/ > ?id=d2d3cada1c56973e27829990e5d87425469ead9f Replacing "Cancel" by "Skip" doesn't improve the situation IMO. "Skip" can just as well be misunderstood to mean "skip squashing".
(In reply to Thomas Wolf from comment #11) > (In reply to Eclipse Genie from comment #10) > > Gerrit change https://git.eclipse.org/r/154799 was merged to [master]. > > Commit: > > http://git.eclipse.org/c/egit/egit.git/commit/ > > ?id=d2d3cada1c56973e27829990e5d87425469ead9f > > Replacing "Cancel" by "Skip" doesn't improve the situation IMO. "Skip" can > just as well be misunderstood to mean "skip squashing". Would you prefer a different label, or a different solution?
Either "Cancel", and cancelling the dialog cancels the squash, or no cancel opportunity at all. The first would make sense for direct user-initiated squashing (Modify->Squash), the second would make sense for squashes done in an interactive rebase. The first would, I think, need a change in JGit.
Pressing "Cancel" should cancel the squash operation.
This label change definitely doesn't improve things. I don't consider this fixed. The point here is that we have three possible outcomes: * User edits the message and clicks "Reword": the edited message is taken and squash finishes (and further rebase steps possibly run). * User edits commit message and clicks "Cancel": the edits are discarded, squash finishes with the unedited text. * User wants to abort the whole squash or rebase operation. The third is missing. I think the best would be to add a third button "Abort". Possibly re-label the "Cancel" button to "Discard Edits", or "Use Original".
"Abort" needs a little support in JGit first. JGit must be able to determine from the result of the callback that it is supposed to abort the rebase. (For instance, if it gets back null.)
Actually, there is another option for the user: stop the rebase, without performing the commit. That is what C git does if you exit the editor with an error code (:cq! in vim) or an empty message. Using C git, the user can then decide what to do: edit the commit further, commit with a new message, or abort the rebase. Maybe that's better for the three options in the dialog? "Reword", "Use Original", "Stop Rebase"? Or give the user four options? "Reword", "Use Original", "Stop Rebase", "Abort"? (We could still distinguish Stop from Abort in JGit, e.g., null result leads to abort, and empty message leads to stop.)
