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

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

Linus Torvalds <torvalds@osdl.org> writes:

Show 5 quoted lines

> ... But I doubt it works very well to rely on 
> commit-level SHA1's - it's more likely to work if you try the "last few 
> tagged releases etc", since patches that don't apply are often against the 
> previous release (and if they don't apply there either, then it's probably 
> not worth fighting over anyway).

That is the heuristics git-applypatch in the proposed updates branch tries to attempt. Recorded tree if exists (which is not very interesting), last few commits from the current branch, and then tagged releases.

Ideally, if we had the path following git-rev-list you talked about, we could first ask git-apply the set of paths the patch touches, and instead of trying every commits from the HEAD, try only commits that touch one (or more) of the given paths.

Another possible git-rev-list enhancement that might be useful is to pop commits not based on time but based on the depth from branch heads. Then we could:

    git-rev-list --depth-order --max-count=$N --all \
    	$(git-apply --show-files $patch | sed -e 's/^[^ ]* [^ ]* //p')

to obtain list of the last few commits that touch the paths involved, in the order that is closer-to-tip first.