On 2/5/2018 1:48 PM, Junio C Hamano wrote:
Jeff King <peff@xxxxxxxx> writes:
The big advantage of your scheme is that you can update the graph index
without repacking. The traditional advice has been that you should
always do a full repack during a gc (since it gives the most delta
opportunities). So metadata like reachability bitmaps were happy to tied
to packs, since you're repacking anyway during a gc. But my
understanding is that this doesn't really fly with the Windows
repository, where it's simply so big that you never obtain a single
pack, and just pass around slices of history in pack format.
So I think I'm OK with the direction here of keeping metadata caches
separate from the pack storage.
OK. I guess that the topology information surviving repacking is a
reason good enough to keep this separate from pack files, and I
agree with your "If they're not tied to packs,..." below, too.
Thanks.
If they're not tied to packs, then I think having a separate builtin
like this is the best approach. It gives you a plumbing command to
experiment with, and it can easily be called from git-gc.
-Peff
Thanks for all the advice here. In addition to the many cleanups that
were suggested, I'm going to take a try at the "subcommand" approach.
I'll use git-submodule--helper and git-remote as models for my
implementation.
Thanks,
-Stolee
