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. A quick change in the pristine_detach function in t3510 and t3511 from "cherry-pick --quit" to "cherry-pick --abort" works when one ignores the return value of "cherry-pick --abort". The "--quit" is used here to ensure a clean cherry-pick state, and --quit always succeeds, even if no cherry-pick is in progress. That may be a real use-case somehow that could also be used for "rebase --forget" t3510 also shows another use-case for --quit: the title says it all: "cherry-pick --quit" to "cherry-pick --abort" With this additional information, I'd vote to keep --quit/--forget and just make it consistent. ~Stephan
