Johannes Sixt <j...@kdbg.org> writes: > 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). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
