Re: pack.packSizeLimit, safety checks

From: Nicolas Pitre <nico@fluxnic.net>
Date: Feb 1, 2010, 16:11 UTC
Message-ID: <alpine.LFD.2.00.1002011100550.1681@xanadu.home>
In-Reply-To: <loom.20100201T101056-232@post.gmane.org>

On Mon, 1 Feb 2010, Sergio wrote:

Show 18 quoted lines

> 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.

Show 7 quoted lines

> 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