On Sun, Nov 10, 2019 at 5:19 PM Derrick Stolee <stolee@xxxxxxxxx> wrote: > > > 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? > > Unfortunately, you're running into an issue because I designed the > "read" subcommand poorly (and also forgot to update it for > incremental commit-graph files). The biggest issue is that "read" > is not really meant for end-users. It really should have been built > as a test-tool. This point was corrected when I got around to writing > the multi-pack-index since it uses "test-tool read-midx" instead of > add. > > To fix this issue, I would probably go about it by removing the "read" > subcommand and creating a "test-tool read-commit-graph" for the tests > that need that output. > > If others on-list think that the better thing to do is to update the > "read" subcommand to provide the same output, but iterate over each > layer of an incremental commit-graph, then I can do that work instead. I was only running "git commit-graph read" as another way of verifying that everything looked good (to Git, that is). I'd already run "git commit-graph verify" and just found the discrepancy in their behavior surprising/interesting. For what it's worth, I personally don't see anything amiss with removing the "read" subcommand if that's simpler than updating it to handle incremental graphs. (Put differently, it's not a command I'd ever have Bitbucket Server run, or that I'm likely to try and run going forward. In this case I just completed some commit graph-related changes to Bitbucket Server and was looking for every possible avenue I could pursue to try and ensure what I did was producing the "correct" output after my changes got deployed to our internal dogfooding server.) Thanks for taking the time to look into it and clarify the behavior! I really appreciate it. Best regards, Bryan Turner > > Thanks, > -Stolee
