Re: pack.packSizeLimit, safety checks

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