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

["Lars Hjemli" <hjemli@gmail.com>]

On Feb 11, 2008 8:48 AM, Jeff King <peff@peff.net> 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