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
> 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
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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html