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

From: Junio C Hamano <junkio@cox.net>
Date: Oct 6, 2005, 00:03 UTC
Message-ID: <7vslvfcy0g.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.64.0510050725510.31407@g5.osdl.org>

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.

> Quite often, the reason it doesn't apply is that I already have that patch 
> through a git merge (or because I applied that patch earlier through 
> another person), in which case I don't even try to merge it, I just delete 
> that email too, and just do "git-applymbox" again.

Thanks. So in short, you do not even need '-c' option, but just trim the mbox you feed to applymbox and re-run it.

While I was experimenting with the git-am (only in 'pu' branch, and still marked as "do not use"), I noticed that it does the right thing on an already applied patch. It fails to apply, finds an appropriate base and then notices the result of the patch application is already contained in the HEAD ;-).