On Fri, Sep 06, 2019 at 01:00:40PM -0400, Derrick Stolee wrote: > On 9/5/2019 4:37 PM, Junio C Hamano wrote: > > Jeff King <p...@peff.net> writes: > > > >> Do we want to to have fetch.writeCommitGraph, receive.writeCommitGraph, > >> and then a master transfer.writeCommitGraph? > > > > If anything, it may be good for consistency. > > > > I am not sure if it is a good idea to trigger writing the commit > > graph when accepting a push, though. It tends to be a lot finer > > grained than fetching, right? > > And I expect a push to include many fewer commits than a fetch. > In a server environment, I would expect to have a separate > maintenance task responsible for updating the commit-graph after > receiving new data, but not in an in-line fashion with the push.
That's probably how we'll end up doing it at GitHub, because we run a big server farm that has a job-queueing system for periodic maintenance, etc. But keep in mind the "little guy" who is hosting a few repositories for themselves or their company. They'd presumably want the benefits here, too, right? We already have options to trigger auto-gc and update-server-info for them, so why not this maintenance, too? > Think about the situation of many pushes that happen in a short > burst: one write after all of the pushes would have close to the > same performance benefits as writing with every push, but does > a lot less work. Sure, but wouldn't that similarly apply to fetching? What is it that makes bursts of pushes more likely than bursts of fetches? -Peff
