From: Junio C Hamano <gitster@pobox.com>
Date: Mon, 05 Feb 2018 18:48:53 GMT
Subject: Re: [PATCH v2 05/14] commit-graph: implement git-commit-graph --write
Message-ID: <xmqqd11jb7ca.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <20180203092806.GA25927@sigill.intra.peff.net>

Jeff King <peff@peff.net> 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