Re: BUG: "cherry-pick A..B || git reset --hard OTHER"

From: Stephan Beyer <s-beyer@gmx.net>
Date: Dec 9, 2016, 19:24 UTC
Message-ID: <e0780f7c-ccb4-29fe-3d72-80e45a202f65@gmx.net>
In-Reply-To: <xmqq8trprn7f.fsf@gitster.mtv.corp.google.com>

Hi Junio,

On 12/09/2016 07:07 PM, Junio C Hamano wrote:

Show 10 quoted lines

> Duy Nguyen <pclouds@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