Re: [PATCH v10] setup: improve error diagnosis for invalid .git files

From: Tian Yuchen <a3205153416@gmail.com>
Date: Feb 23, 2026, 03:35 UTC
Message-ID: <5263825f-163c-43af-bac7-152d670919d9@gmail.com>
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