Re: rename detection limit checking, cherry picking, and git am -3

[Mark Levedahl <mlevedahl@gmail.com>]

Shawn O. Pearce wrote:
> In this case `git am -3` creates a tree object containing only
> the files modified by the patch and then feeds that tree into
> git-merge-recursive.  Now if you go study git-revert's code you'll
> see it actually just calls git-merge-recursive on three trees,
> but these are three complete trees.
>
> So what's probably happening here is there's less candidates on one
> side in the `am -3` case, so we spend a lot less time generating
> the rename matrix, searching for a match, and we get better changes
> of finding a match.
>
>   
Thanks for the explanation. For my case, there are < 500 files 
(including renamed files) in common between the two branches, giving 
~2000*4000 files that have no correspondence for which git can try to 
find renames. Clearly, reducing the one side from 4000 files to 1 file 
has an enormous payoff.

Mark