I found this while doing some digging into fetch behavior and split commit graphs. I had been running fetch.writeCommitGraph=true on my local repos for a while and noticed that the commit-graph chains were much longer than expected. The reason is silly, and the commit message includes all the details. This behavior exists since v2.24.0, so I'm not sure if it makes the bar for v2.25.0 this late in the release cycle. At minimum, the change is very small and unlikely to cause more pain. This is only a performance bug, and the effect is relatively small. A large list of commit-graph files slows down the commit lookup time as we need to perform a linear number of binary searches. This only affects finding the first commit(s) in a commit walk, as after that we can navigate quickly to the correct position using graph_pos. When a user runs gc (with gc.writeCommitGraph=true, on by default), the chain collapses to a single level, fixing the performance problem. Thanks, -Stolee Derrick Stolee (1): fetch: set size_multiple in split_commit_graph_opts builtin/fetch.c | 4 +--- commit-graph.c | 4 +++- 2 files changed, 4 insertions(+), 4 deletions(-) base-commit: 99c33bed562b41de6ce9bd3fd561303d39645048 Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-509%2Fderrickstolee%2Ffetch-write-commit-graph-split-v1 Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-509/derrickstolee/fetch-write-commit-graph-split-v1 Pull-Request: https://github.com/gitgitgadget/git/pull/509 -- gitgitgadget
