Marc Branchaud <> writes:

> On 12-08-10 04:09 PM, Junio C Hamano wrote:
>> Felix Natter <> writes:
>>> I have a few questions about this:
>>>> As I am coming from "large depth is harmful" school, I would
>>>> recommend
>>>>  - "git repack -a -d -f" with large "--window" with reasonably short
>>>>    "--depth" once, 
>>> So something like --depth=250 and --window=500? 
>> I would use more like --depth=16 or 32 in my local repositories.
>>>> and mark the result with .keep;
>>> I guess you refer to a toplevel '.keep' file.
>> Not at all.  And it is not documented, it seems X-<.
>> Typically you have a pair of files in .git/objects/pack, e.g.
>>   .git/objects/pack/pack-2e3e3b332b446278f9ff91c4f497bc6ed2626d00.idx
>>   .git/objects/pack/pack-2e3e3b332b446278f9ff91c4f497bc6ed2626d00.pack
>> And you can add another file next to them
>>   .git/objects/pack/pack-2e3e3b332b446278f9ff91c4f497bc6ed2626d00.keep
>> to prevent the pack from getting repacked.  I think "git clone" does
>> this for you after an initial import.
> 1.7.12.rc1 does not.

Sorry, I misremembered.  It was removed at 1db4a75 (Remove
unnecessary pack-*.keep file after successful git-clone,
2008-07-08), so even when the sender gave you a crappy pack, you can
repack locally to correct it.

> Maybe clone should preserve the packs it gets from the upstream repo?

That was part of the intention of the code 1db4a75 removed.

> For
> example, our main repo has a 690MB pack file that's marked .keep, but the
> clone just ends up with a single 725MB pack file.  Would our clones see
> performance improvements if they that big 690MB pack separate from the others?

There is no "pack boundary" in the object transfer protocol.  What
comes out of the wire is a single stream of pack data, so the above
is not feasible without major surgery and backward incompatible
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to