is commitGraph useful on the server side?

Hi, all:

I've read the docs on commitGraph and it's not 100% clear to me if turning it on and generating commit graphs would be useful on the server-side. I know it's going to be enabled by default and automatically generated whenever "git gc" runs, so I'm trying to figure out if it'll be useful for git-daemon operations.

Thanks in advance for your help.

Best, -K

On 10/22/2019 12:51 PM, Konstantin Ryabitsev wrote:

I've CC'd Taylor Blau for more information here.

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.

If you are managing reachability bitmaps, then most of the server-side stuff will use the bitmaps instead. However, creating those bitmaps will be slightly faster with the commit-graph.

If you don't use bitmaps, then the commit-graph will help fetch negotiation and many other commit-walk experiences.

If you have a lot of machinery around your server maintenance, then you can schedule commit-graph updates more frequently than bitmap computations, and you would get benefit by parsing commits faster in the zone "above" the bitmaps.

Thanks, -Stolee

On Tue, Oct 22, 2019 at 03:44:28PM -0400, Derrick Stolee wrote:

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.

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).

But I agree that there's no reason _not_ to use them.

-Peff

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

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

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

[resending, looks like we lost Konstantin from the cc]

On Tue, Oct 22, 2019 at 03:44:28PM -0400, Derrick Stolee wrote:

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.

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).

But I agree that there's no reason _not_ to use them.

-Peff