{"thread":{"id":"52092","subject":"is commitGraph useful on the server side?","startedAt":"2019-10-22T16:51:19Z","lastAt":"2019-10-22T20:39:27Z","messageCount":5,"participants":["Konstantin Ryabitsev","Derrick Stolee","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"384612","messageId":"20191022165112.GA4960@chatter.i7.local","threadId":"52092","inReplyTo":null,"subject":"is commitGraph useful on the server side?","fromName":"Konstantin Ryabitsev","fromEmail":"konstantin@linuxfoundation.org","sentAt":"2019-10-22T16:51:12Z","receivedAt":"2019-10-22T16:51:19Z","isPatch":false,"sender":{"key":"konstantin@linuxfoundation.org","avatar":"https://gravatar.com/avatar/7cb8827c6de56e1bd2dea16508c6708aa43feed3bf3813bcdacecdf96ceadd79?d=mp&s=160"},"body":"Hi, all:\n\nI've read the docs on commitGraph and it's not 100% clear to me if \nturning it on and generating commit graphs would be useful on the \nserver-side. I know it's going to be enabled by default and \nautomatically generated whenever \"git gc\" runs, so I'm trying to figure \nout if it'll be useful for git-daemon operations.\n\nThanks in advance for your help.\n\nBest,\n-K\n"},{"id":"384622","messageId":"e0e294a7-bd3c-2174-a922-c5893b0945c2@gmail.com","threadId":"52092","inReplyTo":"20191022165112.GA4960@chatter.i7.local","subject":"Re: is commitGraph useful on the server side?","fromName":"Derrick Stolee","fromEmail":"stolee@gmail.com","sentAt":"2019-10-22T19:44:28Z","receivedAt":"2019-10-22T19:44:32Z","isPatch":false,"sender":{"key":"stolee@gmail.com","avatar":"https://avatars.githubusercontent.com/u/570044?v=4"},"body":"On 10/22/2019 12:51 PM, Konstantin Ryabitsev wrote:\n> Hi, all:\n> \n> 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.\n> \n> Thanks in advance for your help.\n\nI've CC'd Taylor Blau for more information here.\n\nI'm biased, but I think the commit-graph is generally really good to have\nin almost all cases. I actually do not know of a good reason to _not_ have\nit.\n\nIf you are managing reachability bitmaps, then most of the server-side\nstuff will use the bitmaps instead. However, creating those bitmaps will\nbe slightly faster with the commit-graph.\n\nIf you don't use bitmaps, then the commit-graph will help fetch negotiation\nand many other commit-walk experiences.\n\nIf you have a lot of machinery around your server maintenance, then you\ncan schedule commit-graph updates more frequently than bitmap computations,\nand you would get benefit by parsing commits faster in the zone \"above\" the\nbitmaps.\n\nThanks,\n-Stolee\n"},{"id":"384624","messageId":"20191022200615.GA12270@sigill.intra.peff.net","threadId":"52092","inReplyTo":"e0e294a7-bd3c-2174-a922-c5893b0945c2@gmail.com","subject":"Re: is commitGraph useful on the server side?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-10-22T20:06:16Z","receivedAt":"2019-10-22T20:06:19Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Oct 22, 2019 at 03:44:28PM -0400, Derrick Stolee wrote:\n\n> I'm biased, but I think the commit-graph is generally really good to have\n> in almost all cases. I actually do not know of a good reason to _not_ have\n> it.\n\nA lot depends on how much you do on the server. If you're serving a web\ninterface that runs things like `rev-list`, or `for-each-ref\n--contains`, etc, then you should see a big improvement.\n\nIf you're _just_ serving fetches with `upload-pack`, you might see some\nsmall improvement during fetch negotiation. But I suspect it would be\ndwarfed by the cost of actually generating packs. Likewise, the\ntraversal there will be dominated by accessing trees (and if that is\nexpensive, then you ought to be using reachability bitmaps).\n\nBut I agree that there's no reason _not_ to use them.\n\n-Peff\n"},{"id":"384625","messageId":"20191022200728.GB12270@sigill.intra.peff.net","threadId":"52092","inReplyTo":"e0e294a7-bd3c-2174-a922-c5893b0945c2@gmail.com","subject":"Re: is commitGraph useful on the server side?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-10-22T20:07:28Z","receivedAt":"2019-10-22T20:07:30Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"[resending, looks like we lost Konstantin from the cc]\n\nOn Tue, Oct 22, 2019 at 03:44:28PM -0400, Derrick Stolee wrote:\n\n> I'm biased, but I think the commit-graph is generally really good to have\n> in almost all cases. I actually do not know of a good reason to _not_ have\n> it.\n\nA lot depends on how much you do on the server. If you're serving a web\ninterface that runs things like `rev-list`, or `for-each-ref\n--contains`, etc, then you should see a big improvement.\n\nIf you're _just_ serving fetches with `upload-pack`, you might see some\nsmall improvement during fetch negotiation. But I suspect it would be\ndwarfed by the cost of actually generating packs. Likewise, the\ntraversal there will be dominated by accessing trees (and if that is\nexpensive, then you ought to be using reachability bitmaps).\n\nBut I agree that there's no reason _not_ to use them.\n\n-Peff\n"},{"id":"384627","messageId":"20191022203923.GA3020@chatter.i7.local","threadId":"52092","inReplyTo":"20191022200615.GA12270@sigill.intra.peff.net","subject":"Re: is commitGraph useful on the server side?","fromName":"Konstantin Ryabitsev","fromEmail":"konstantin@linuxfoundation.org","sentAt":"2019-10-22T20:39:23Z","receivedAt":"2019-10-22T20:39:27Z","isPatch":false,"sender":{"key":"konstantin@linuxfoundation.org","avatar":"https://gravatar.com/avatar/7cb8827c6de56e1bd2dea16508c6708aa43feed3bf3813bcdacecdf96ceadd79?d=mp&s=160"},"body":"On Tue, Oct 22, 2019 at 04:06:16PM -0400, Jeff King wrote:\n>> I'm biased, but I think the commit-graph is generally really good to \n>> have\n>> in almost all cases. I actually do not know of a good reason to _not_ have\n>> it.\n>\n>A lot depends on how much you do on the server. If you're serving a web\n>interface that runs things like `rev-list`, or `for-each-ref\n>--contains`, etc, then you should see a big improvement.\n\nAh, good to know, so something like cgit would see an improvement if \nthere are commit graphs generated for the repos it serves.\n\n>If you're _just_ serving fetches with `upload-pack`, you might see some\n>small improvement during fetch negotiation. But I suspect it would be\n>dwarfed by the cost of actually generating packs. Likewise, the\n>traversal there will be dominated by accessing trees (and if that is\n>expensive, then you ought to be using reachability bitmaps).\n\nWe do generate bitmaps on a routine basis.\n\nOK, I think I'm convinced that enabling commitgraph and generating them \nregularly is going to be a net win.\n\nThanks, everyone.\n\n-K\n\n"}]}