Thread (11 messages) flat view 11 messages, 4 authors, 2016-06-15

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help