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