On Thu, 14 Nov 2013 18:55:52 +0400
Лежанкин Иван <[email protected]> wrote:
> I hit this limit in file 'diffcore-rename.c':
>
> if (rename_limit <= 0 || rename_limit > 32767)
> rename_limit = 32767;
>
> I just guess, that this limit comes from the O(N^2) complexity of the
> comparison algorithm. Since the max 32-bit signed value is 2^31, then
> the 2^15 = 32768 is somehow correlated with its square root, maybe,
> like 2^(32/2 - 1) - to prevent overflow.
> I'm trying to prepare the patch right now, that changes the `int
> rename_limit` => `long rename_limit` and all intermediate variable
> types. Is it a correct way to do?
I beleive rename_limit comes from reading the diff.renameLimit
configuration variable. The gitconfig(1) manual page hints to look at
the "-l" command-line option of `git diff` which is described this way:
-l<num>
The -M and -C options require O(n^2) processing time where n is the
number of potential rename/copy targets. This option prevents
rename/copy detection from running if the number of rename/copy
targets exceeds the specified number.
This description is not too clear, I admit.
Looks like you're on the right track but the patch appears to require a
more wide impact:
* 32767 should be a default limit, applied in the case the user did not
specify neither diff.renameLimit nor "-l".
* If whatever value read from those sources is less than 0, an error
should be thrown--it looks strange to just revert it to the default
value in this case.
* If the user-supplied value is >= 0, then just use it, assume the user
knows what they are doing.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
