Re: is commitGraph useful on the server side?

From: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Date: Oct 22, 2019, 20:39 UTC
Message-ID: <20191022203923.GA3020@chatter.i7.local>
In-Reply-To: <20191022200615.GA12270@sigill.intra.peff.net>

On Tue, Oct 22, 2019 at 04:06:16PM -0400, Jeff King wrote:

Show 8 quoted lines

>> I'm biased, but I think the commit-graph is generally really good to 
>> have
>> in almost all cases. I actually do not know of a good reason to _not_ have
>> it.
>
>A lot depends on how much you do on the server. If you're serving a web
>interface that runs things like `rev-list`, or `for-each-ref
>--contains`, etc, then you should see a big improvement.

Ah, good to know, so something like cgit would see an improvement if there are commit graphs generated for the repos it serves.

Show 5 quoted lines

>If you're _just_ serving fetches with `upload-pack`, you might see some
>small improvement during fetch negotiation. But I suspect it would be
>dwarfed by the cost of actually generating packs. Likewise, the
>traversal there will be dominated by accessing trees (and if that is
>expensive, then you ought to be using reachability bitmaps).

We do generate bitmaps on a routine basis.

OK, I think I'm convinced that enabling commitgraph and generating them regularly is going to be a net win.

Thanks, everyone.

-K