Marc Branchaud <mbranch...@xiplink.com> writes: > On 12-08-10 04:09 PM, Junio C Hamano wrote: >> Felix Natter <fnat...@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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
