From: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Date: Tue, 22 Oct 2019 20:39:23 GMT
Subject: Re: is commitGraph useful on the server side?
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:
>> 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