Re: Dangerous "git am --abort" behavior

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 21, 2010, 00:30 UTC
Message-ID: <7vtyi8arxp.fsf@alter.siamese.dyndns.org>
In-Reply-To: <AANLkTinP4SArMkjvTXOEG=tf=8EcEdP9fPAB7F=iitSc@mail.gmail.com>

Linus Torvalds <torvalds@linux-foundation.org> writes:

Show 8 quoted lines

> I just noticed this, and I wonder if it has bitten me before without
> me noticing: "git am --abort" can be really dangerous.
>
> What happened today was that I had been doing a pull or two, and then
> applied an emailed patch with "git am" as usual. But as sometimes
> happens, I actually had a previous "git am" that had failed - in fact,
> it was the same patch that I applied today that had had an earlier
> version that no longer applied.

I never got into this as I use bash completion in my PS1 in the real life, but I've seen this happen while playing around, and I can see myself easily getting hurt by this behaviour without status in PS1.

Show 6 quoted lines

> Maybe "git am" should actually save the last commit ID that it did,
> and only do the "reset" if the current HEAD matches the rebase-apply
> state and warns if it doesn't? Or maybe we could just introduce a new
> "git am --clean" that just flushes any old pending state (ie does that
> "clean_abort" thing, which is basically just the "rm -rf" I've done by
> hand). Or both?

I sometimes wanted "--clean" myself, so it is a no-brainer to decide that it would be a good thing to add.

The last time I thought about this issue, I wasn't sure about "compare with the last commit"---mostly because it wasn't clear what ramifications it would have. When you get refusal from "am --abort", how would you recover from it?

Back then my tentative conclusion was actually to get rid of "am --abort" and give "am --clean", making the final "reset HEAD~$n" the responsiblity of the user. But I forgot to pursue it.