All of lore.kernel.org
 help / color / mirror / Atom feed
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 14:23:32 -0800	[thread overview]
Message-ID: <xmqq4in8quxn.fsf@gitster.g> (raw)
In-Reply-To: <20260222102928.377519-1-a3205153416@gmail.com> (Tian Yuchen's message of "Sun, 22 Feb 2026 18:29:28 +0800")

Tian Yuchen <a3205153416@gmail.com> writes:

> 'read_gitfile_gently()' treats any non-regular file as
> 'READ_GITFILE_ERR_NOT_A_FILE' and fails to discern between 'ENOENT'
> and other stat failures. This flawed error reporting is noted by two
> 'NEEDSWORK' comments.
>
> Address these comments by introducing two new error codes:
> 'READ_GITFILE_ERR_STAT_ENOENT' and 'READ_GITFILE_ERR_IS_A_DIR'.
>
> To preserve the original intent of the setup process:
> 1. Update 'read_gitfile_error_die()' to treat 'IS_A_DIR' as a no-op
>    (like 'ENOENT'), while still calling 'die()' on true 'NOT_A_FILE'
>    errors.
> 2. Unconditionally pass '&error_code' to 'read_gitfile_gently()'. This
>    eliminates an uninitialized variable hazard that occurred when
>    'die_on_error' was true and 'NULL' was passed.
> 3. Only invoke 'is_git_directory()' when we explicitly receive
>    'READ_GITFILE_ERR_IS_A_DIR', avoiding redundant filesystem checks.
> 4. Correctly return 'GIT_DIR_INVALID_GITFILE' on unrecognized errors
>    when 'die_on_error' is false.
>
> Additionally, audit external callers of 'read_gitfile_gently()' in
> 'submodule.c' and 'worktree.c' to accommodate the refined error codes.
>
> Signed-off-by: Tian Yuchen <a3205153416@gmail.com>
> ---
>  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.


  parent reply	other threads:[~2026-02-22 22: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 [this message]
2026-02-23  0:23         ` Junio C Hamano
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=xmqq4in8quxn.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.