On Feb 11, 2008 12:08 PM, Jeff King <peff@xxxxxxxx> wrote: > 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. Additionally git could warn if the limit is reached in the merge. Santi - 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
