Re: 64-bit support.

From: Лежанкин Иван <abyss.7@gmail.com>
Date: Nov 14, 2013, 14:55 UTC
Message-ID: <CAJc7Lbp2gF18xAM1z-NCo8cp73px_-RTqGcB1MiPup9iGn+uRw@mail.gmail.com>
In-Reply-To: <27C8BBEE-128F-4CC1-AACE-248CA0CD8FBE@acm.org>

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@acm.org> wrote:

Show 20 quoted lines

> 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@gmail.com> 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@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html