On 12-08-10 04:09 PM, Junio C Hamano wrote: > Felix Natter <fnatter@xxxxxxx> 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. I even cloned from a repo with a few .keep files, but ended up with only one big .pack file. Maybe clone should preserve the packs it gets from the upstream repo? 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? Perhaps the fact that clone creates a single pack file makes it impossible to preserve the .keep packs from the upstream? (I figure it's probably not a good idea for clone to .keep the single pack file it creates.) M. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html