Re: [PATCH 02/10] pack-objects: add --partial-by-size=n --partial-special
- Date: Wed, 8 Mar 2017 15:21:11 -0500
- From: Jeff Hostetler <git@xxxxxxxxxxxxxxxxx>
- Subject: Re: [PATCH 02/10] pack-objects: add --partial-by-size=n --partial-special
On 3/8/2017 1:47 PM, Junio C Hamano wrote:
Jeff Hostetler <jeffhost@xxxxxxxxxxxxx> writes:
From: Jeff Hostetler <git@xxxxxxxxxxxxxxxxx>
Teach pack-objects to omit blobs from the generated packfile.
When the --partial-by-size=n[kmg] argument is used, only blobs
smaller than the requested size are included. When n is zero,
no blobs are included.
Does this interact with a more traditional way of feeding output of
an external "rev-list --objects" to pack-objects via its standard
input, and if so, should it (and if not, shouldn't it)?
It is perfectly OK if the answer is "this applies only to the case
where we generate the list of objects with internal traversal." but
that needs to be documented and discussed in the proposed log
Let me study that and see. I'm still thinking thru ways and
options for doing the sparse-checkout like filtering.
When the --partial-special argument is used, git special files,
such as ".gitattributes" and ".gitignores" are included.
And not ."gitmodules"?
What happens when we later add ".gitsomethingelse"?
Do we have to worry about the case where the set of git "special
files" (can we have a better name for them please, by the way?)
understood by the sending side and the receiving end is different?
I have a feeling that a mode that makes anything whose name begins
with ".git" excempt from the size based cutoff may generally be
easier to handle.
I forgot about ".gitmodules". The more I think about it, maybe
we should always include them (or anything starting with ".git*")
and ignore the size, since they are important for correct behavior.
I am not sure how "back-filling" of a resulting narrow clone would
safely be done and how this impacts "git fsck" at this point, but if
they are solved within this effort, that would be a very welcome