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