Re: 64-bit support.

From: Konstantin Khomoutov <flatworm@users.sourceforge.net>
Date: Nov 14, 2013, 15:11 UTC
Message-ID: <20131114191131.dd568689c8a2ac5f0dd7b04c@domain007.com>
In-Reply-To: <CAJc7Lbp2gF18xAM1z-NCo8cp73px_-RTqGcB1MiPup9iGn+uRw@mail.gmail.com>

On Thu, 14 Nov 2013 18:55:52 +0400 Лежанкин Иван <abyss.7@gmail.com> wrote:

Show 12 quoted lines

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