Am 24.05.2016 um 00:11 schrieb Junio C Hamano:
Johannes Sixt <j6t@xxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html