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
