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

From: Lars Hjemli <hjemli@gmail.com>
Date: Feb 11, 2008, 10:41 UTC
Message-ID: <8c5c35580802110241i72169620s693a31f9a098f596@mail.gmail.com>
In-Reply-To: <20080211074817.GA18898@sigill.intra.peff.net>

On Feb 11, 2008 8:48 AM, Jeff King <peff@peff.net> wrote:

Show 15 quoted lines

> 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