At $WORK, we've had a few occasions where someone's commit-graph becomes corrupt, and hits various BUG()s that block their day-to-day work. When this happens, we advise the user to either disable the commit graph, or to delete it and let it be regenerated. It would be a nicer user experience if we can make this a self-serve procedure. To do this, let's add a new `git commit-graph clear` subcommand so that users don't need to manually delete files under their .git directories. And to make it self-documenting, update various BUG(), die(), and error() messages to suggest removing the commit graph to recover from the corruption. This approach was suggested in [1] and generally positively received [2], but was never implemented. [1] https://lore.kernel.org/git/YBoBBie2t1EhcLAN@xxxxxxxxxx/ [2] https://lore.kernel.org/git/xmqqk0rpc7uj.fsf@xxxxxxxxxxxxxxxxxxxxxx/ Open questions for reviewers: * Should we turn this into an advice setting instead? * Should we also suggest running `commit-graph write` after clearing the graph? I lean towards no; everything will still function as normal without a commit graph. * Does it make sense to add the suggestion in all of these corruption error messages? There are many other error()s in commit-graph.c, should we add this for all of them, or just the ones that specifically mention corruption? Or maybe just the fatal BUG()s and die()s? * Any other places this suggestion should be added that I've missed? Josh Steadmon (2): commit-graph: add `git commit-graph clear` subcommand commit-graph: suggest removing corrupt graphs Documentation/git-commit-graph.txt | 5 ++++ builtin/commit-graph.c | 40 +++++++++++++++++++++++++++ commit-graph.c | 43 +++++++++++++++++++++++++++--- commit-graph.h | 1 + commit-reach.c | 4 ++- t/t5318-commit-graph.sh | 17 ++++++++++-- t/t5324-split-commit-graph.sh | 26 ++++++++++++------ 7 files changed, 122 insertions(+), 14 deletions(-) base-commit: 3e0d3cd5c7def4808247caf168e17f2bbf47892b -- 2.44.0.rc0.258.g7320e95886-goog
