public inbox for git@vger.kernel.org
 help / color / mirror / Atom feed
From: Tian Yuchen <a3205153416@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Karthik Nayak <karthik.188@gmail.com>
Subject: Re: [PATCH v10] setup: improve error diagnosis for invalid .git files
Date: Mon, 23 Feb 2026 11:35:46 +0800	[thread overview]
Message-ID: <5263825f-163c-43af-bac7-152d670919d9@gmail.com> (raw)
In-Reply-To: <xmqqqzqcpatz.fsf@gitster.g>

Hi Junio,

 >> 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'").

I must admit I hadn't considered this edge case at all. Thank you for 
pointing it out :]

>> 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.

Hummm, I believe it is safe. From the perspective of 
'read_gitfile_gently()', the sole purpose is to locate and read a 
repository file. Whether 'stat()' returns 'ENOENT' (the file physically 
does not exist) or 'ENOTDIR' (a component of the path is not a 
directory, making it impossible for the file to exist there), the 
functional result is exactly the same: the '.git' file is missing.

But I must say I can't 100% guarantee its safety. Anyway, lemme just do 
what I can for now.

I will:
  - squash your diff into my patch
  - rename the error code to `READ_GITFILE_ERR_STAT_MISSING`
  - combine this with the commit message refinements and test cleanups 
suggested by Karthik in the previous thread.

Thank you for the patch and for walking me through this edge case. I'll 
send out v11 soon! (2~3 hours later)

Regards,

Yuchen

  reply	other threads:[~2026-02-23  3:35 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
2026-02-23  3:35           ` Tian Yuchen [this message]
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=5263825f-163c-43af-bac7-152d670919d9@gmail.com \
    --to=a3205153416@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=karthik.188@gmail.com \
    /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