On Mon, Feb 11, 2008 at 11:41:05AM +0100, Lars Hjemli wrote: > > 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
