Jon Seymour <jon.seymour@xxxxxxxxx> writes: > On Thu, Apr 5, 2012 at 8:59 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> Jon Seymour <jon.seymour@xxxxxxxxx> writes: >> >>> Are there any flaws, I wonder? >> >> It all depends on how close the base is to M^1. ... > > True. I guess it is still true there are no perfect solutions in this > area. This does seem like a step in a better direction, though. The nice thing about Hannes's "replay the change between M^1 and M" is that it sidesteps the fundamentally impossible part of your original idea, which is to mechanically sift the "evil" part out of "pure merge" part out. Instead, it replays the change as a single ball of wax. That difference between these two approaches may make the replaying of M easier or harder, depending on how M^1 and your new base relate to each other, so it is hard to say if it is really a step in a better direction. Perhaps M is a merge made to the maint branch, and you may be replaying it on top of a newer codebase based on the master track. M^1 may lack many changes the new base has, so replaying M by applying the patch between M^1 and M may give you a lot of conflict that you should not have to resolve if you simply merged M^2 to the new base. And the worst part of this conflict resolution is that you cannot easily tell what the right solution should be unless you look at M, M^1 and M^2---that forces you to sift the "evil" part out of "pure merge" part in the original merge. The good news is that this is *not* mechanical, as you have your own intelligence to help that process ;-) -- 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