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