Re: limiting rename detection during merge is a really bad idea

On Mon, Feb 11, 2008 at 11:41:05AM +0100, Lars Hjemli wrote:

quoted

It may also be that multiple rename limits are appropriate. I don't mind
waiting 30 seconds for rename detection during a particularly tricky
merge. I probably do when running 'git-log -p'.

Yeah, I guess we could add support for merge.renamelimit in addition
to diff.renamelimit (i.e. use diff.renamelimit if merge.renamelimit is
unspecified). And/or add the -l option of git-diff-* to
git-merge.sh/merge-recursive.c.

Perhaps we should first figure out what reasonable default values are. I
think the reported problem was not "Oh, I didn't expect my tweaked
diff.renamelimit to affect merge" but rather "I didn't tweak
diff.renamelimit at all".

The mega-commit I was playing with that caused Linus to suggest
diff.renamelimit in the first place is 374 by 641 (src by dest) and
completes in ~15 minutes. The case recently reported in "git-revert is a
memory hog" is 3541 by 8043, and doesn't complete ever.  We limit to 100
by 100 by default.

Steffen, can you tell us how large your rename set is (unfortunately,
there is no way to get this information easily; you can stop
merge-recursive in the debugger at diffcore-rename.c:457 and look at
num_src and num_create). And how long it takes to run with
diff.renamelimit turned off?

That might give us a clue where a reasonable value is.

-Peff