"Derrick Stolee via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > The commit-graph feature is starting to stabilize. Based on what is in > master right now, we have: > > Git 2.18: > > * Ability to write commit-graph (requires user interaction). > > > * Commit parsing is faster when commit-graph exists. > > > * Must have core.commitGraph true to use. > > > > Git 2.19: > > * Ability to write commit-graph on GC with gc.writeCommitGraph. > > > * Generation numbers written in commit-graph > > > * A few reachability algorithms make use of generation numbers. > > > > (queued for) master: > > * The test suite passes with GIT_TEST_COMMIT_GRAPH=1 > > > * 'git commit-graph write' has progress indicators. > > > * The commit-graph is automatically disabled when grafts or replace-objects > exist. If I recall correctly, one more task that was discussed but hasn't been addressed well is how the generation and incremental update of it should integrate with the normal repository maintenance workflow (perhaps "gc --auto"). If we are going to turn it on by default, it would be good to see if we can avoid multiple independent walks done over the same history graph by repack, prune and now commit-graph, before such a change happens. Thanks.
