On Feb 11, 2008 8:48 AM, Jeff King <peff@xxxxxxxx> wrote: > On Mon, Feb 11, 2008 at 07:19:32AM +0100, Steffen Prohaska wrote: > > > I think that limiting rename detection during merge is a really > > bad idea. Either we should set it to unlimited, or at least we > > should print a BIG WARNING that rename detection is limited > > during the merge. I'd propose to override diff.renamelimit > > to unlimited for a merge, even if diff.renamelimit is explicitly > > configured by the user. It doesn't make sense not to detect > > renames during a merge. > > > > Opinions? > > The point of diff.renamelimit was that some rename detection is > literally so time-consuming that we might as well not bother starting > it. The number '100' was pulled out of Linus', er, hat. FWIW, prior to 07b45f8c merge-recursive ignored diff.renamelimit. The effect of this was that 'git diff HEAD somebranch' could detect renames which 'git merge somebranch' couldn't; Teaching merge-recursive about diff.renamelimit made sense IMHO since 'git merge' then would agree with 'git diff' regarding renames. > 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. -- larsh - 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
