Re: git repack vs git gc --aggressive

Marc Branchaud [off-list ref] writes:

On 12-08-10 04:09 PM, Junio C Hamano wrote:

quoted

Felix Natter [off-list ref] writes:

quoted

I have a few questions about this:

quoted

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.

quoted

quoted

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.