On Fri, Sep 06, 2019 at 02:46:22PM -0700, Junio C Hamano wrote: > > You're right that we could isolate the new write to the refs we > > just received. We could use the more cumbersome write_commit_graph() > > method with a list of commit oids as starting points. I'm happy to > > make that change if we see a lot of value there. > > Well, that is not the kind of information reuse I am talking about. > > I was wondering if "index-pack" has enough information in-core after > it receives and processes the incoming pack data, scanned each and > every object in it, in order to write out the commit graph _without_ > having to do a lot of duplicate computation and enumeration of the > objects done in the current commit-graph.c::write_commit_graph(), so > that it can learn a "--write-commit-graph" option that performs much > better than running "git fetch && git commit-graph write". > > Perhaps that would require too much refactoring of both index-pack > and commit-graph code and infeasible in short to medium term and > that is why I said "for longer term, it feels a bit unfortunate". I think the basic metadata should be easy. We have each commit expanded in memory at some point, so parsing it and filing away its parents, trees, etc isn't too hard. Generation numbers are a little trickier, though, because they imply an actual topological traversal. It might actually be easier to couple this with the connectivity check we do after index-pack finishes (though I've often wondered if we could drop that check in favor of making index-pack smarter about finding the boundaries). -Peff
