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

From: Steffen Prohaska <prohaska@zib.de>
Date: Feb 11, 2008, 13:29 UTC
Message-ID: <EFA2BCB7-B552-4952-B1EC-53307DA9972E@zib.de>
In-Reply-To: <8aa486160802110320h78f7228fg84ae2c4986f67372@mail.gmail.com>

On Feb 11, 2008, at 12:20 PM, Santi Béjar wrote:

Show 5 quoted lines

>> 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?

I don't know the size. I can only say that it took a few seconds on a MacBook Pro.

>> That might give us a clue where a reasonable value is.
>
> Additionally git could warn if the limit is reached in the merge.

I think this would have saved me. I did not know about the rename limit. Therefore I did not understand why the merge failed. If git merge had reported that the rename detection limit was reached, I probably would have looked up what this limit is about. At least git should tell when rename detection gets disabled. Users expect that renames work and git should tell the user when it does not even try to detect renames.

Personally, I can easily switch to a larger machine if this helps completing a merge and I think I would do this. But I also know that I shouldn't expect too much from a larger machine for an O(n^2) algorithm.

	Steffen