> The commit-graph file is a very helpful feature for speeding up git > operations. In order to make it more useful, make it possible to > write the commit-graph file during standard garbage collection > operations. > > Add a 'gc.commitGraph' config setting that triggers writing a > commit-graph file after any non-trivial 'git gc' command. Defaults to > false while the commit-graph feature matures. We specifically do not > want to have this on by default until the commit-graph feature is fully > integrated with history-modifying features like shallow clones. So I played around with an earlier version of this patch series a while ago... and as I looked into my gitconfig today I was surprised to have both 'core.commitGraph' and 'gc.commitGraph' config variables set. When I looked into it I came across this email from Ævar: https://public-inbox.org/git/87fu3peni2.fsf@xxxxxxxxxxxxxxxxxxx/ > Other than the question if 'gc.commitGraph' and 'core.commitGraph' > should be independent config variables, and the exact wording of the > git-gc docs, it looks good to me. Sans doc errors you pointed out in other places (you need to set core.commitGraph so it's read at all), I think it's very useful to have these split up. It's simliar to pack.useBitmaps & pack.writeBitmaps. I think the comparison with pack bitmaps makes a lot of sense and I have to say that I really like those 'useBitmaps' and 'writeBitmaps' variable names, because it's clear right away which one is which, without consulting the documentation. I think having 'useCommitGraph' and 'writeCommitGraph' variables would be a lot better than the same variable name in two different sections, and I'm sure that then I wouldn't have been caught off guard. Yeah, I know, my timing sucks, with 'core.commitGraph' already out there in the -rc releases... sorry.
