Re: [PATCH] git-{repack,pack-objects} accept --{pack,blob}-limit to control pack size

From: Nicolas Pitre <nico@cam.org>
Date: Apr 4, 2007, 22:04 UTC
Message-ID: <alpine.LFD.0.98.0704041750030.28181@xanadu.home>
In-Reply-To: <56b7f5510704041340l5997b04dp853e8270a644ab28@mail.gmail.com>

On Wed, 4 Apr 2007, Dana How wrote:

> The motivations are to better support portable media,
> older filesystems,  and larger repositories without
> awkward enormous packfiles.

I wouldn't qualify "enormous" pack files as "awkward".

It will always be more efficient to have only one pack to deal with (when possible of course).

Show 7 quoted lines

> When --pack-limit[=N] is specified and --stdout is not,
> all bytes in the resulting packfile(s) appear at offsets
> less than N (which defaults to 1<<31).  The default
> guarantees mmap(2) on 32b systems never sees signed off_t's.
> The object stream may be broken into multiple packfiles
> as a result,  each properly and conventionally built.
>

This sounds fine. *However* how do you ensure that the second pack (or subsequent packs) is self contained with regards to delta base objects when it is _not_ meant to be a thin pack?

Show 6 quoted lines

> When --stdout is also specified,  all objects in the
> resulting packfile(s) _start_ at offsets less than N.
> All the packfiles appear concatenated on stdout,
> and each has its object count set to 0.  The behavior
> without --stdout cannot be duplicated here since
> lseek(2) is not generally possible on stdout.

Please scrap that. There is simply no point making --pack-limit and --stdout work together. If the amount of data to send over the GIT protocol exceeds 4G (or whatever) it is the receiving end's business to split it up _if_ it wants/has to. The alternative is just too ugly.

Show 5 quoted lines

> When --blob-limit=N is specified,  blobs whose uncompressed
> size is greater than or equal to N are omitted from the pack(s).
> If --pack-limit is specified, --blob-limit is not, and
> --stdout is not,  then --blob-limit defaults to 1/4
> of the --pack-limit.

Is this really useful?

If you have a pack size limit and a blob cannot make it even in a pack of its own then you're screwed anyway. It is much better to simply fail the operation than leaving some blobs behind. IOW I don't see the usefulness of this feature.

Nicolas