Re: Small rerere in rebase regression

From: Junio C Hamano <gitster@pobox.com>
Date: May 23, 2016, 22:11 UTC
Message-ID: <xmqqk2ik77cr.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <57437693.3030106@kdbg.org>

Johannes Sixt <j6t@kdbg.org> writes:

Show 10 quoted lines

> I also come to the conclusion that die_with_patch shouldn't have to
> have a call to "git rerere". die_with_patch can be called after "git
> cherry-pick", "git merge", "git commit", all of which have their own
> rerere() invocation.
>
> However, calling "git rerere" after a failed "git commit" may be
> destructive: it would record a resolution even though the commit has
> not be completed. Think of an squash commit being aborted because the
> user notices an error in the last minute. If that error is in a
> conflict resolution, that wrong resolution would be recorded.

So, the behaviour change you observed uncovered a small bug in "rebase -i" that was covered by the old limitation of "rerere" that refrained from creating preimage when there already is one?

I think removing the call to "git rerere" there is a safe and sensible thing regardless, but perhaps authors of "rebase -i" had their own reasons. I dunno (it is unlikely I'll have a chance to do blame and digging today).