On 9/6/2019 4:42 PM, Junio C Hamano wrote: > Jeff King <p...@peff.net> writes: > >> I suppose so. But I think the "stock git without any other job >> infrastructure" case would still benefit. > > Oh, no question about it. > > I did question if an automatic writing would benefit the side that > receives a push when you brought up the usual "fetch.* and receive.* > for separate configuration, transfer.* when want to rule them both" > convention, which is a good idea if only for consistency, but the > question was if it helps the receiving end of a push to the same > degree as it would help the repository that fetches.
I think the "stock git without any other job infrastructure" is a very important scenario. Putting the simplest version of "commit-graph writes in-line with every push" seems to be ripe for failure under load. I'd rather think deeply about what is best for this scenario. Spit-balling: what if we used the same mechanism as running GC in the background to launch 'git commit-graph write' commands? And we could have the command give up (without failure) if the commit-graph.lock file is already created, so concurrent pushes would not fight each other. Thanks, -Stolee
