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

From: Johannes Sixt <j.sixt@viscovery.net>
Date: Aug 28, 2013, 06:39 UTC
Message-ID: <521D9B14.2070408@viscovery.net>
In-Reply-To: <20130827214808.GA26350@sigill.intra.peff.net>

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

Show 17 quoted lines

> 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