Re: [PATCH] Fall back to three-way merge when applying a patch.

Linus Torvalds [off-list ref] writes:

On Thu, 6 Oct 2005, Eric W. Biederman wrote:

quoted

After thinking about it I don't think you need to look through the
history to use it for a merge3 operation.   As I recall merge3 only
looks at the base and the two derived versions of the file.  If we
have the sha1 of the original in the git repository I think all we
need to compute is the diff between that sha1 the current version
file.  And then apply the merge3 algorithm to combine the two sets of
changes.

Ahh, that I can definitely agree with. In fact, it makes perfect sense.

However, it assumes that everybody is a git user, which isn't actually 
true. 

Agreed.  The question is the subset of everyone large enough to
make it a useful technique.  Given that a standalone diff utility can
be taught how to generate the extra information, and a standalone
patch could use it to verify you are at least patching the version
of the file the patch was intended for I suspect the subset of
everyone is large enough to be interesting.

Also, I'm wondering whether the advantages outweigh the 
disadvantages: it would make the diff uglier. We'd have to add that SHA1 
there somewhere (either on the "diff" line itself, or as anothe rextended 
git line like the "rename from/to" lines - a "original <sha1>" line).

I don't think an extra line in the header is going to be much of a problem.
Just more header noise.  

Eric