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

Linus Torvalds [off-list ref] writes:

... 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).

Yes.  That is the current heuristics git-applypatch in the
proposed updates branch tries to attempt.  Recorded tree if
exists (which is not very interesting), last few commits, 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 last few commits that touch the paths
involved, in the order that is closer-to-tip first.  This would
give us set of more useful commits than the current behaviour.