Re: [PATCH 0/2] commit-graph: suggest deleting corrupt graphs

[Junio C Hamano <gitster@pobox.com>]

Josh Steadmon <steadmon@google.com> writes:

> 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.

I am of two minds.

For one, if we know there is a corruption and if we know that we
will certainly recover cleanly if we removed these files, it would
be fair for an end-user to respond with: instead of telling me to
run "commit-graph clear", you can run it for me, can't you?

The other one is if it hinders debugging the root cause to run
"clear", whether it is done by the end-user or by the mechanism that
detects and dies upon discovery of a corruption.  Do we know how
these commit-graph files become corrupt?  How valuable would these
corrupt files be to help us track down where the corruption comes
from?  If they are not all that useful in debugging, then removing
them ourselves or telling users to remove them may be OK, of course.

Do these BUG()s come from corruption that can be diagnosed upfront
when we "open" the commit-graph files?  I am wondering if it would
be the matter of teaching prepare_commit_graph() to check for
corruption and return without enabling the support.

Thanks.