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

From: Eric W. Biederman <ebiederm@xmission.com>
Date: Oct 6, 2005, 01:59 UTC
Message-ID: <m1mzln9zi1.fsf@ebiederm.dsl.xmission.com>
In-Reply-To: <7vslvfcy0g.fsf@assigned-by-dhcp.cox.net>

Junio C Hamano <junkio@cox.net> writes:

Show 15 quoted lines

> Linus Torvalds <torvalds@osdl.org> writes:
>
>> ... Although I would actually prefer to be able to try against
>> a specific named release (not "all named tags" first).
>
> That makes sense, given that you know better than the tool can
> possibly guess, especially from the performance point of view.
>
> What's interesting is that from the correctness point of view,
> it should not make that much of a difference which base tree
> happens to be picked -- if the base tree is wildly different
> from your current HEAD, most of that wild difference will be
> carried over intact to the result of patch application for paths
> and parts of the files the patch does not touch.  Three-way
> merge notices that and your "changes" from the base tree win.

There is another workable strategy. Modify git-diff-xxx to report the sha1 of the tree, or the sha1's of the files the patch applies to. And make that information available to git-apply. I don't how often it would help but it has the possibility of letting the tools know exactly what the patch applied against.

A rational for why this would work is that is that a kernel repository is large, and unless objects/alternatives can be made to work across servers there will be people who can use git for development but can't host a repository that can be pulled from. Especially for a small patch.

Using sha1's for context before merging should be able to give you a whole lot more machine verifiable context with just a little bit of work.

Eric