From: Josh Steadmon <steadmon@google.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 0/2] commit-graph: suggest deleting corrupt graphs
Date: Wed, 24 Apr 2024 12:30:05 -0700 [thread overview]
Message-ID: <sc4xgsvzioqglqtsaqww56vctehfzkomy7wr574y3su6optu6t@punugznrq7bk> (raw)
In-Reply-To: <xmqqwmqw82pv.fsf@gitster.g>
On 2024.02.22 16:05, Junio C Hamano wrote:
> 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.
Sorry for the late reply, this got buried in my inbox. The corruption we
saw was related to a generation numbers bug [1] that I think was only
present for a short while in 'next'.
[1] https://lore.kernel.org/git/YBn3fxFe978Up5Ly@google.com/
I believe that being able to examine the files after the corruption was
detected did help us narrow down the issue, so I would lean towards not
automatically deleting them upon detecting corruption.
I don't think that this case would be detectable without running a full
`git commit-graph verify` up front.
next prev parent reply other threads:[~2024-04-24 19:30 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-22 23:19 [PATCH 0/2] commit-graph: suggest deleting corrupt graphs Josh Steadmon
2024-02-22 23:19 ` [PATCH 1/2] commit-graph: add `git commit-graph clear` subcommand Josh Steadmon
2024-02-22 23:19 ` [PATCH 2/2] commit-graph: suggest removing corrupt graphs Josh Steadmon
2024-02-23 0:05 ` [PATCH 0/2] commit-graph: suggest deleting " Junio C Hamano
2024-04-24 19:30 ` Josh Steadmon [this message]
2024-04-24 21:28 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=sc4xgsvzioqglqtsaqww56vctehfzkomy7wr574y3su6optu6t@punugznrq7bk \
--to=steadmon@google.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).