On Wed, May 23, 2012 at 11:53 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > I think your original point was that the above clean picture would not > hold if e-b and g-b has interactions. g-b may contain some change that > e-b has independently done, in which case e'-g would be made smaller than > e-b when the conflict is resolved while replaying e to produce e' on top > of c' (the same applies if you replace e with any commit in the dag > "rev-list ^b e d"). The merge to produce f' may result in conflicts, > whether you merge e' and d' or replay f-e on top of e'. Right. Or if e' was changed as a result of a "edit" action (I meant to include '-i' in addition to '-p'). > A better way to keep potential "evil merges" at f while replaying to > produce f' may *not* be by applying the difference f-e on top of e'. > Instead, you can learn from what 'rerere' does. That is, to attempt a > mechanical merge between e and d and call the result (with possible > conflict markers and all) pre-f. If you compare pre-f and f, that is the > resolution and evil change made at f. When reproducing f', mechanically > merge e' and d', call the result (again, with possible conflict markers > and all) pre-f', and try reproducing f' by a 3-way merge between pre-f, > pre-f' and f. Yes, I've had the same idea myself. Anyway, as Johannes said, that's probably something to consider for the sequencer. Martin -- 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