Re: Small rerere in rebase regression

From: Johannes Sixt <j6t@kdbg.org>
Date: May 24, 2016, 20:46 UTC
Message-ID: <5744BD97.4070902@kdbg.org>
In-Reply-To: <xmqqk2ik77cr.fsf@gitster.mtv.corp.google.com>

Am 24.05.2016 um 00:11 schrieb Junio C Hamano:

Show 10 quoted lines

> Johannes Sixt <j6t@kdbg.org> writes:
>> 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 had a closer look, and found that the failure mode I described does not occur: after having resolved a commit, the user can call "git rebase --continue", but the "git commit" invocation that occurs there is guarded with a mere 'die', not 'die_with_patch'.

All other "git commit" guarded with 'die_with_patch' are either not interactive or are after a non-conflicting merge or cherry-pick (and so there was no opportunity to resolve a conflict).

-- Hannes