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?
On 14 November 2013 18:40, Kent R. Spillner <kspillner@xxxxxxx> wrote:
> Can you be more specific about the limitation you suspect you are hitting? 32,768 is not the "max 32-bit value."
>
>
>> On Nov 14, 2013, at 6:58, Лежанкин Иван <abyss.7@xxxxxxxxx> wrote:
>>
>> Hi!
>>
>> Do you plan to implement the 64-bit support in git? - Right now I have
>> a problems sometimes with a huge repo and renaming detection. If I
>> merge more than 32768 files at once, then the renaming detection
>> fails, because of limitation inside git. The limitation is put by max
>> 32-bit value.
>>
>> I tweaked sources locally, to use 64-bit value as a number of merging
>> files - generally, it works. But I'm not so brave to try to replace it
>> everywhere in git.
>> --
>> 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
--
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