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

From: Eric W. Biederman <ebiederm@xmission.com>
Date: Oct 6, 2005, 17:07 UTC
Message-ID: <m1slvek20w.fsf@ebiederm.dsl.xmission.com>
In-Reply-To: <Pine.LNX.4.64.0510060756060.31407@g5.osdl.org>

Linus Torvalds <torvalds@osdl.org> writes:

Show 14 quoted lines

> On Thu, 6 Oct 2005, Eric W. Biederman wrote:
>> 
>> 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