Hi, On Mon, 23 May 2016, Junio C Hamano wrote: > Johannes Sixt <j6t@xxxxxxxx> 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). I introduced this in ecfe72ff658124ea301ec7b2bb8b987689303685, as a (late) answer to f131dd492f098f9f565df93df13e35c734284590. Hannes, could you quickly test whether https://github.com/dscho/git/tree/interactive-rebase calls rerere twice, too? (Please call interactive rebase with the GIT_USE_REBASE_HELPER=true to avoid running the interactive rebase twice.) I have a hunch that it does not call rerere twice, which would be a nice bonus in that patch thicket (so far, I split the patches into seven patch series, in addition to the ones I already sent, still have to do one thorough review before I'll continue submitting them). Ciao, Dscho -- 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