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

[ebiederm@xmission.com (Eric W. Biederman)]

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

> 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