On Mon, 1 Feb 2010, Sergio wrote: > Hi, > > documentation about pack.packSizeLimit > > says: > > The default maximum size of a pack. This setting only affects packing to a file, > i.e. the git:// protocol is unaffected. It can be overridden by the > --max-pack-size option of git-repack(1). > > I would suggest clarifying it into > > The default maximum size of a pack in bytes. This setting only affects packing > to a file, i.e. the git:// protocol is unaffected. It can be overridden by the > --max-pack-size option of git-repack(1). > > Since --max-pack-size takes MB and one might be tempted to assume that the same > is valid for pack.packSizeLimit. Grrrrr. This is a terrible discrepency given that all the other arguments in Git are always byte based, with the optional k/m/g suffix, by using git_parse_ulong(). So IMHO I'd just change --max-pack-size to be in line with all the rest and have it accept bytes instead of MB. And of course I'd push such a change to be included in v1.7.0 along with the other incompatible fixes. Your suggested precision above is still worth it of course. > Also note that some safety check on pack.packSizeLimit could probably be > desirable to avoid an unreasonably small limit. For instance: > > Assume that pack.packSizeLimit is set to 1 (believing it would be 1MB, but it is > in fact 1B). With this at the first git gc every object goes in its own pack. > You realize the mistake, you fix pack.packSizeLimit to 1000000, but at this > point you cannot go back since git gc cannot run anymore (too many open files). That's a totally orthogonal issue. There are other ways to get into trouble with too many open files and that deserves a fix of its own (such as limiting the number of simultaneous opened packs). Nicolas -- 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