Re: [PATCH v2 0/2] DEFAULT_DOC_TARGET

[Jeff King <peff@peff.net>]

On Thu, Jan 03, 2013 at 02:20:31PM -0800, Junio C Hamano wrote:

> Jeff King <peff@peff.net> 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