From: Junio C Hamano <gitster@pobox.com>
To: Tian Yuchen <a3205153416@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH v10] setup: improve error diagnosis for invalid .git files
Date: Sun, 22 Feb 2026 16:23:04 -0800 [thread overview]
Message-ID: <xmqqqzqcpatz.fsf@gitster.g> (raw)
In-Reply-To: <xmqq4in8quxn.fsf@gitster.g> (Junio C. Hamano's message of "Sun, 22 Feb 2026 14:23:32 -0800")
Junio C Hamano <gitster@pobox.com> writes:
>> setup.c | 42 ++++++++++++++------
>> setup.h | 2 +
>> submodule.c | 2 +-
>> t/meson.build | 1 +
>> t/t0009-git-dir-validation.sh | 72 +++++++++++++++++++++++++++++++++++
>> worktree.c | 6 ++-
>> 6 files changed, 110 insertions(+), 15 deletions(-)
>> create mode 100755 t/t0009-git-dir-validation.sh
>
> We'd probably need to treat ENOTDIR the same way as ENOENT to deal
> with cases where we expect a directory "sm1" to be the root of a
> submodule working tree, and we have a modification that removes the
> submodule directory and replace it with a regular file "sm1". In
> the code path touched by this patch in submodule.c, we would ask "is
> sm1/.git a git directory?" and the stat(2) call on that path in
> read_gitfile_gently() used to say "Ah, a failure, that means we
> cannot positively say that 'sm1/.git' is a git directory or a gitdir
> file." Now we inspect the error code in an attempt to tell if it is
> a system failure (e.g., a corrupt filesystem), but catching only
> ENOENT is probably a bit too tight. In the above scenario, asking
> about 'sm1/.git' when 'sm1' is a regular file will not result in
> ENOENT but in ENOTDIR (i.e., "the leading 'sm1' is not a directory so
> it makes no sense to ask about 'sm1/.git'").
>
> Is it always sensible to treat ENOTDIR and ENOENT as two equivalent
> errors for the purpose of read_gitfile_gently()? I have no clear
> answer offhand myself. This is part of what we need to think about
> and resolve while addressing the original "NEEDSWORK:" comment.
----- >8 -----
Subject: [PATCH] read_gitfile(): group ENOENT and ENOTDIR into a
single MISSING error
The code from the previous step does not deal wellwith a case where
we check if "sm/.git" is a good directory after replacing "sm" with
a regular file. ENOTDIR is returned when we ask about "sm/.git",
not ENOENT, and the code would want to handle both.
I am not convinced if this is a good change, though. Outside the
submodule caller, the story might be different and we may want to
treat ENOTDIR differently from ENOENT. I dunno. That is why this
is not squashed into the patch (yet).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
setup.c | 8 ++++----
setup.h | 2 +-
submodule.c | 2 +-
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/setup.c b/setup.c
index b79a9233f5..d4afbed3eb 100644
--- a/setup.c
+++ b/setup.c
@@ -895,7 +895,7 @@ int verify_repository_format(const struct repository_format *format,
void read_gitfile_error_die(int error_code, const char *path, const char *dir)
{
switch (error_code) {
- case READ_GITFILE_ERR_STAT_ENOENT:
+ case READ_GITFILE_ERR_STAT_MISSING:
case READ_GITFILE_ERR_IS_A_DIR:
/* non-fatal; follow return path */
break;
@@ -943,8 +943,8 @@ const char *read_gitfile_gently(const char *path, int *return_error_code)
static struct strbuf realpath = STRBUF_INIT;
if (stat(path, &st)) {
- if (errno == ENOENT)
- error_code = READ_GITFILE_ERR_STAT_ENOENT;
+ if (errno == ENOENT || errno == ENOTDIR)
+ error_code = READ_GITFILE_ERR_STAT_MISSING;
else
error_code = READ_GITFILE_ERR_STAT_FAILED;
goto cleanup_return;
@@ -1589,7 +1589,7 @@ static enum discovery_result setup_git_directory_gently_1(struct strbuf *dir,
gitdirenv = read_gitfile_gently(dir->buf, &error_code);
if (!gitdirenv) {
switch (error_code) {
- case READ_GITFILE_ERR_STAT_ENOENT:
+ case READ_GITFILE_ERR_STAT_MISSING:
/* no .git in this directory, move on */
break;
case READ_GITFILE_ERR_IS_A_DIR:
diff --git a/setup.h b/setup.h
index c23629cb4f..cc45f962fa 100644
--- a/setup.h
+++ b/setup.h
@@ -36,7 +36,7 @@ int is_nonbare_repository_dir(struct strbuf *path);
#define READ_GITFILE_ERR_NO_PATH 6
#define READ_GITFILE_ERR_NOT_A_REPO 7
#define READ_GITFILE_ERR_TOO_LARGE 8
-#define READ_GITFILE_ERR_STAT_ENOENT 9
+#define READ_GITFILE_ERR_STAT_MISSING 9
#define READ_GITFILE_ERR_IS_A_DIR 10
void read_gitfile_error_die(int error_code, const char *path, const char *dir);
const char *read_gitfile_gently(const char *path, int *return_error_code);
diff --git a/submodule.c b/submodule.c
index 52a7cf0e43..fc85a7a1d8 100644
--- a/submodule.c
+++ b/submodule.c
@@ -2413,7 +2413,7 @@ void absorb_git_dir_into_superproject(const char *path,
const struct submodule *sub;
struct strbuf sub_gitdir = STRBUF_INIT;
- if (err_code == READ_GITFILE_ERR_STAT_ENOENT) {
+ if (err_code == READ_GITFILE_ERR_STAT_MISSING) {
/* unpopulated as expected */
strbuf_release(&gitdir);
return;
--
2.53.0-455-g62fcd67e6e
next prev parent reply other threads:[~2026-02-23 0:23 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-18 12:46 [PATCH v6 0/2] setup: allow cwd/.git to be a symlink to a directory Tian Yuchen
2026-02-18 12:46 ` [PATCH v6 1/2] setup: distinguish ENOENT from other stat errors Tian Yuchen
2026-02-18 12:46 ` [PATCH v6 2/2] setup: allow cwd/.git to be a symlink to a directory Tian Yuchen
2026-02-19 7:16 ` [PATCH v7] " Tian Yuchen
2026-02-20 3:40 ` Junio C Hamano
2026-02-20 16:27 ` Tian Yuchen
2026-02-20 16:45 ` [PATCH v8] " Tian Yuchen
2026-02-20 18:00 ` Junio C Hamano
2026-02-21 8:10 ` Tian Yuchen
2026-02-21 17:20 ` Junio C Hamano
2026-02-22 3:22 ` Tian Yuchen
2026-02-21 8:30 ` [PATCH v9] setup: improve error diagnosis for invalid .git files Tian Yuchen
2026-02-22 5:42 ` Junio C Hamano
2026-02-22 10:28 ` Tian Yuchen
2026-02-22 10:29 ` [PATCH v10] " Tian Yuchen
2026-02-22 16:53 ` Karthik Nayak
2026-02-23 7:00 ` Tian Yuchen
2026-02-22 22:23 ` Junio C Hamano
2026-02-23 0:23 ` Junio C Hamano [this message]
2026-02-23 3:35 ` Tian Yuchen
2026-02-23 5:10 ` Junio C Hamano
2026-02-23 15:39 ` Junio C Hamano
2026-02-23 17:17 ` Tian Yuchen
2026-02-23 19:27 ` Junio C Hamano
2026-02-24 10:23 ` Tian Yuchen
2026-02-24 17:01 ` Tian Yuchen
2026-02-25 2:50 ` Junio C Hamano
2026-02-25 16:03 ` Tian Yuchen
2026-02-23 7:44 ` [PATCH v11] " Tian Yuchen
2026-02-26 23:03 ` Junio C Hamano
2026-02-27 5:26 ` Tian Yuchen
2026-02-27 22:20 ` Junio C Hamano
2026-02-28 4:38 ` Tian Yuchen
2026-03-02 16:26 ` Junio C Hamano
2026-03-03 19:31 ` Phillip Wood
2026-03-04 5:39 ` Junio C Hamano
2026-03-04 11:03 ` Tian Yuchen
2026-03-04 16:53 ` Junio C Hamano
2026-03-04 17:35 ` Tian Yuchen
2026-03-04 18:06 ` Junio C Hamano
2026-03-04 18:41 ` Tian Yuchen
2026-03-04 22:50 ` Junio C Hamano
2026-03-05 12:40 ` Tian Yuchen
2026-03-09 23:30 ` Junio C Hamano
2026-03-04 14:15 ` [PATCH v12] " Tian Yuchen
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=xmqqqzqcpatz.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=a3205153416@gmail.com \
--cc=git@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.