Split commit graphs and commit-graph read
- From
Bryan Turner <bturner@atlassian.com>
- Date
- Nov 8, 2019, 23:41 UTC
- Message-ID
- <CAGyf7-G3NDp--2nUbri_0EqvSLF21M0gsFCOKDCWMY+e68Htog@mail.gmail.com>
Just a quick question about a behavior I've noticed with the commit graph. (Amazing feature, by the way!)
If the _very first_ write done is split: git commit-graph write --reachable --split
You end up with something like this: .../objects$ ls -R info info: commit-graphs packs
info/commit-graphs: commit-graph-chain graph-6612fcc8fd04d3af2cc268a6bd9161ae40f5fcbf.graph
info/commit-graph doesn't exist, but I have a 1-graph "chain" in place. (And subsequent write --split calls write additional ones; I've got a few now in this repository, but still no info/commit-graph.)
git commit-graph verify seems happy: .../objects$ git commit-graph verify Verifying commits in commit graph: 100% (98768/98768), done.
But git commit-graph read isn't: .../objects$ git commit-graph read fatal: Could not open commit-graph '/path/to/repository/objects/info/commit-graph': No such file or directory
Running some tests with commands like git for-each-ref and git rev-list shows that the "split" commit graph is being used (setting core.commitGraph=false makes commands noticeably slower), so functionally all seems well. But should git commit-graph read be handling this better?
Best regards, Bryan Turner