is commitGraph useful on the server side?

is commitGraph useful on the server side?

[Konstantin Ryabitsev]

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

Re: is commitGraph useful on the server side?

[Derrick Stolee]

On 10/22/2019 12:51 PM, Konstantin Ryabitsev wrote:
> 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.

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

Re: is commitGraph useful on the server side?

[Jeff King]

On Tue, Oct 22, 2019 at 03:44:28PM -0400, Derrick Stolee 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.

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

Re: is commitGraph useful on the server side?

[Konstantin Ryabitsev]

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

Re: is commitGraph useful on the server side?

[Jeff King]

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

On Tue, Oct 22, 2019 at 03:44:28PM -0400, Derrick Stolee 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.

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