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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox