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

From: Mark Levedahl <mlevedahl@gmail.com>
Date: Sep 18, 2007, 00:18 UTC
Message-ID: <46EF1953.6060106@gmail.com>
In-Reply-To: <20070917034742.GG3099@spearce.org>

Shawn O. Pearce wrote:

Show 12 quoted lines

> 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