Re: What's cooking in git.git (Aug 2013, #06; Tue, 27)

Am 8/27/2013 23:48, schrieb Jeff King:

The counterarguments I can see are:

  1. Who cares? If you want to know whether pack-objects will choke on
     your huge config value, then run pack-objects.

  2. Such a check would involve knowing which type we use internally to
     look at packSizeLimit, and that is utterly undocumented (and
     subject to change; e.g., it seems kind of senseless that we have a
     4G pack-size limit on 32-bit platforms, and we may want to fix
     that).

So if you do not buy the argument that communicating git's internal
range checks is useful, then we can simply say "--int is magically long
on every platform, and you can use it for everything numeric". And
implement it with int64_t. You may be able to read or write some values
for certain keys that git will barf on internally, but that is git's
problem.

I'm in the camp of these (counter) arguments.

When my shell script asks for 'git config --int 3g', I expect to be
returned a positive 10-digit. What would I care which type Git or any
other tool is using internally? I only care whether my shell can work with
numbers that large. Or the next tool that I feed the number to. But that's
my business, not Git's.

The one thing it doesn't get you is that you can currently set unsigned
values to "-1" in the config to have them treated as ULONG_MAX. This is
undocumented and as far as I know not used by anyone.

And it better stays that way. Magic numbers should be encoded with magic
strings in the config file.

-- Hannes