Re: [PATCH] git-{repack,pack-objects} accept --{pack,blob}-limit to control pack size
From: Nicolas Pitre <hidden>
Date: 2016-06-15 22:43:03
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).
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?
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.
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