Re: is commitGraph useful on the server side?

[Konstantin Ryabitsev <konstantin@linuxfoundation.org>]

On Tue, Oct 22, 2019 at 04:06:16PM -0400, Jeff King wrote:
>> 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.

>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