Re: git repack vs git gc --aggressive
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Aug 13, 2012, 17:19 UTC
- Message-ID
- <7vr4raemkj.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <50290D1F.20007@xiplink.com>
Marc Branchaud <mbranchaud@xiplink.com> writes:
Show 34 quoted lines
> On 12-08-10 04:09 PM, Junio C Hamano wrote: >> Felix Natter <fnatter@gmx.net> 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 change.