Re: [RFC PATCH] am: do not do any reset on --abort

[Avery Pennarun <apenwarr@gmail.com>]

On Mon, May 25, 2009 at 12:02 PM, Jeff King <peff@peff.net> wrote:
> On Mon, May 25, 2009 at 02:17:48PM +0200, Johannes Sixt wrote:
>
>> I wonder why we have this problem (and do something about it) with git-am,
>> but not with git-rebase. Is it perhaps that the usual case were people
>> were bitten by the old behavior is:
>
> I don't know. I had assumed a safety valve we put in git-am might need
> to be matched in rebase. But I don't recall whether I have screwed
> myself in the same way with rebase. Perhaps because rebase happens on a
> detached HEAD, I tend to notice sooner that something is not right.

Ah, maybe that's the difference.  rebase seems to detach the HEAD,
then do a bunch of stuff, then reset the original branch only when
it's done.  So aborting doesn't reset any branches at all, it just
checks out the original branch.

Thus one option would be to try to make am more like rebase: detach
the HEAD before it starts, and reattach it only on success.  At least
then you only have one set of UI problems to fix.

(Of course, I've gotten myself into trouble anyway by checking new
stuff in on the detached HEAD and later aborting a rebase.  I have
quite a love-hate relationship with detached HEADs.)

Maybe the best solution here isn't to prevent people from shooting
themselves in the foot, but instead to help them recover afterwards.
I've noticed most people don't know about 'git reflog'; they often
seem astonished when I tell them about it.  reflog + not blowing away
dirty repositories would mean that you're always safe.

Have fun,

Avery