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
