On Sat, Dec 10, 2016 at 2:24 AM, Stephan Beyer <s-be...@gmx.net> wrote: > Hi Junio, > > On 12/09/2016 07:07 PM, Junio C Hamano wrote: >> Duy Nguyen <pclo...@gmail.com> writes: >>> Having the same operation with different names only increases git >>> reputation of bad/inconsistent UI. Either forget is renamed to quit, >>> or vice versa. I prefer forget, but the decision is yours and the >>> community's. So I'm sending two patches to rename in either direction. >>> You can pick one. >> >> I actually was advocating to remove both by making --abort saner. >> With an updated --abort that behaves saner, is "rebase --forget" >> still necessary? > > A quick change in t3407 of the "rebase --forget" test to use "rebase > --abort" failed. That's because it checks the use-case of > forgetting/aborting without changing the HEAD. So --abort makes a > rollback, --forget just keeps the current head. I am not sure if that > tested use-case is a real use-case though.
It is. I wanted something like this for years but "rm -rf /path/to/.git/rebase*" was not as bad when there were no linked worktrees. rebase and cherry-pick/revert are not exactly in the same situation. When cherry-pick/revert in "continue/abort" mode, there's usually some conflicted files and it's easy to notice. But an interactive rebase could stop at some commit with clean worktree (the 'edit' command). Then I could even add some more commits on top. I don't see how 'rebase --abort' can know my intention in this case, whether I tried (with some new commits) and failed, and want to revert/abort the whole thing, moving HEAD back to the original; or whether I forgot I was in the middle of rebase and started to do something else, and --abort needs to keep HEAD where it is. -- Duy
