On Thu, Jan 03, 2013 at 02:20:31PM -0800, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> writes: > > > Not surprising for such a large refactoring, but this has conflicts with > > what's in next. Here's the patch to apply on top of the conflicted tree > > you get from merging this with "next": > > Yeah, verifying the manual fixup is a bit tricky indeed. The output from > > $ git blame -C HEAD^.. -- config.mak.uname | grep '^[^^]' > > shows only the first line of the resulting file, and the output from > > $ git blame --reverse -C HEAD^.. -- Makefile | grep '^^' > > shows only the three-line "Platform specific tweaks" comment, which > was replaced by your version in config.mak.uname, so nothing extra > was added and nothing important was lost between the two, it seems. Yeah, it's probably easier to do than verify. I knew that my patch was a straight copy/paste move of the big if/else block, replacing it with the include. So the obvious resolution is to mechanically move the "theirs" block from next in the same way. And then the resulting diff shows the fixup (which you can verify does not do anything fancy). It's really the same logic that merge-recursive uses for full-file renames, except that git is not smart enough to figure out that it was a 500-line block that moved, not the whole file. It comes up rarely enough that it is probably not worth trying to teach the merge machinery about code block movement. But it would be cool. :) -Peff -- 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