git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: is commitGraph useful on the server side?

From
Jeff King <peff@peff.net>
Date
Oct 22, 2019, 20:07 UTC
Message-ID
<20191022200728.GB12270@sigill.intra.peff.net>
In-Reply-To
<e0e294a7-bd3c-2174-a922-c5893b0945c2@gmail.com>
[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
Previous: Konstantin Ryabitsev
Message 5 of 5 in “is commitGraph useful on the server side?”
  1. Konstantin RyabitsevOct 22, 2019
  2. Derrick StoleeOct 22, 2019
  3. Jeff KingOct 22, 2019
  4. Konstantin RyabitsevOct 22, 2019
  5. Jeff KingOct 22, 2019

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.