From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Johannes Sixt <j6t@kdbg.org>, Git Mailing List <git@vger.kernel.org>
Subject: Re: [PATCH 0/3] fsck index files from all worktrees
Date: Fri, 24 Feb 2023 09:30:44 -0800 [thread overview]
Message-ID: <xmqqr0uf0y4b.fsf@gitster.g> (raw)
In-Reply-To: <Y/hv0MXAyBY3HEo9@coredump.intra.peff.net> (Jeff King's message of "Fri, 24 Feb 2023 03:05:36 -0500")
Jeff King <peff@peff.net> writes:
> We do fsck the resolve-undo extension, but I think fsck just doesn't
> know anything about worktrees. That should be easy enough to fix.
> Patches below.
> ...
> Thanks, it was nice to have a test case. I ended up writing a separate
> test with a missing blob, just because that's simpler to do. It looks
> like we don't test fsck_resolve_undo() or fsck_cache_tree() at all. That
> might be a nice addition, but I punted for now to stay focused on the
> worktree aspects.
So we had a separate worktree with its index pointing at an object
by its resolve-undo (or cache-tree) extension, but somehow lost that
object to gc (I agree with your assessment that it should no longer
happen since 2017). gc these days knows about looking at the index
of all worktrees, finds the issue, and stops for safety. fsck that
is run in the primary worktree may not have noticed but fsck run
from that worktree would notice the issue.
Sounds like a frustrating one.
Thanks, both, for finding and fixing.
next prev parent reply other threads:[~2023-02-24 17:30 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-18 9:38 Bug: fsck and repack don't agree when a worktree index extension is "broken" Johannes Sixt
2023-02-24 8:05 ` [PATCH 0/3] fsck index files from all worktrees Jeff King
2023-02-24 8:07 ` [PATCH 1/3] fsck: factor out index fsck Jeff King
2023-02-24 8:09 ` [PATCH 2/3] fsck: check index files in all worktrees Jeff King
2023-02-24 8:45 ` Jeff King
2023-02-24 8:12 ` [PATCH 3/3] fsck: mention file path for index errors Jeff King
2023-05-11 6:39 ` Eric Sunshine
2023-05-11 16:17 ` Jeff King
2023-05-11 16:28 ` Eric Sunshine
2023-05-11 17:01 ` Jeff King
2023-06-29 18:21 ` Eric Sunshine
2023-06-29 19:37 ` Junio C Hamano
2023-06-01 12:15 ` Andreas Schwab
2023-06-01 14:04 ` Jeff King
2023-02-24 17:30 ` Junio C Hamano [this message]
2023-02-26 22:29 ` [PATCH 4/3] fsck: check even zero-entry index files Jeff King
2023-02-27 12:09 ` Derrick Stolee
2023-02-27 15:58 ` Junio C Hamano
2023-02-26 21:49 ` [PATCH 0/3] fsck index files from all worktrees Johannes Sixt
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=xmqqr0uf0y4b.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=j6t@kdbg.org \
--cc=peff@peff.net \
/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).