On Sun, Nov 10, 2019 at 08:19:20PM -0500, Derrick Stolee wrote: > > 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. In theory I suppose one could use it to debug a commit-graph file "in the field" as it were, where somebody does not necessarily have the test-tool programs. But in practice, I have not ever done that (I didn't even know "commit-graph read" was there), and it's not that big a deal to just have a build of git.git handy. I'd be much more likely to use "commit-graph verify". And perhaps it could grow a "--verbose" flag if somebody really wants that (but I think it would be fine to punt until somebody cares enough to do so). I guess dropping the sub-command is technically a backwards incompatible change, but since it didn't do anything that normal users would find useful in the first place, I wouldn't be sorry to see it go. -Peff
