From: Eric W. Biederman Date: Thu, 06 Oct 2005 01:59:34 GMT Subject: Re: [PATCH] Fall back to three-way merge when applying a patch. Message-ID: In-Reply-To: <7vslvfcy0g.fsf@assigned-by-dhcp.cox.net> Junio C Hamano writes: > Linus Torvalds 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