Re: [PATCH 02/10] pack-objects: add --partial-by-size=n --partial-special
- From
- Jeff Hostetler <git@jeffhostetler.com>
- Date
- Mar 8, 2017, 20:21 UTC
- Message-ID
- <1c38ffbc-e4a2-32e5-d324-506c2111043e@jeffhostetler.com>
- In-Reply-To
- <xmqqh93338s2.fsf@gitster.mtv.corp.google.com>
On 3/8/2017 1:47 PM, Junio C Hamano wrote:
Show 19 quoted lines
> Jeff Hostetler <jeffhost@microsoft.com> writes: > >> From: Jeff Hostetler <git@jeffhostetler.com> >> >> 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 > message. >
Let me study that and see. I'm still thinking thru ways and options for doing the sparse-checkout like filtering.
Show 14 quoted lines
>> 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.
Show 7 quoted lines
> 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 > change. > > Thanks. >