From: Eric Sunshine <sunshine@sunshineco.com>
To: Jeff King <peff@peff.net>
Cc: Git Mailing List <git@vger.kernel.org>, Johannes Sixt <j6t@kdbg.org>
Subject: Re: [PATCH 3/3] fsck: mention file path for index errors
Date: Thu, 11 May 2023 02:39:59 -0400 [thread overview]
Message-ID: <305ccc55-25e3-6b01-cd86-9a9035839d06@sunshineco.com> (raw)
In-Reply-To: <Y/hxW9i9GyKblNV4@coredump.intra.peff.net>
On 2/24/23 3:12 AM, Jeff King wrote:
> If we encounter an error in an index file, we may say something like:
>
> error: 1234abcd: invalid sha1 pointer in resolve-undo
>
> But if you have multiple worktrees, each with its own index, it can be
> very helpful to know which file had the problem. So let's pass that path
> down through the various index-fsck functions and use it where
> appropriate. After this patch you should get something like:
>
> error: 1234abcd: invalid sha1 pointer in resolve-undo of .git/worktrees/wt/index
>
> That's a bit verbose, but since the point is that you shouldn't see this
> normally, we're better to err on the side of more details.
>
> I've also added the index filename to the name used by "fsck
> --name-objects", which will show up if we find the object to be missing,
> etc. This is bending the rules a little there, as the option claims to
> write names that can be fed to rev-parse. But there is no revision
> syntax to access the index of another worktree, so the best we can do is
> make up something that a human will probably understand.
>
> I did take care to retain the existing ":file" syntax for the current
> worktree. So the uglier output should kick in only when it's actually
> necessary. See the included tests for examples of both forms.
This made me think of the work Duy did[1,2] to make it possible to
reference per-worktree refs from other worktrees which allows one to
say, for instance:
git rev-parse main-worktree/HEAD:somefile
git rev-parse worktrees/foo/HEAD:somefile
but, of course, that special syntax doesn't extend to "index", so your
made-up syntax is probably good enough.
[1]: 3a3b9d8cde (refs: new ref types to make per-worktree refs visible
to all worktrees, 2018-10-21)
[2]: ab3e1f78ae (revision.c: better error reporting on ref from
different worktrees, 2018-10-21)
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> diff --git a/builtin/fsck.c b/builtin/fsck.c
> @@ -795,7 +797,8 @@ static int fsck_resolve_undo(struct index_state *istate)
> -static void fsck_index(struct index_state *istate)
> +static void fsck_index(struct index_state *istate, const char *index_path,
> + int is_main_index)
This adds an `is_main_index` flag, but...
> @@ -993,12 +998,19 @@ int cmd_fsck(int argc, const char **argv, const char *prefix)
> + if (read_index_from(&istate, path,
> get_worktree_git_dir(wt)) > 0)
> - fsck_index(&istate);
> + fsck_index(&istate, path, wt->is_current);
...this accesses `is_current`, the value of which is "true" only for the
worktree in which the Git command was run, which is not necessarily the
main worktree. The main worktree, on the other hand, is guaranteed to be
the first entry returned by get_worktrees(), so shouldn't this instead be:
worktrees = get_worktrees();
for (p = worktrees; *p; p++) {
...
fsck_index(&istate, path, p == worktrees);
...
}
free_worktrees(worktrees);
Or am I fundamentally misunderstanding something?
next prev parent reply other threads:[~2023-05-11 6:41 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 [this message]
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 ` [PATCH 0/3] fsck index files from all worktrees Junio C Hamano
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=305ccc55-25e3-6b01-cd86-9a9035839d06@sunshineco.com \
--to=sunshine@sunshineco.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).