public inbox for git@vger.kernel.org
 help / color / mirror / Atom feed
From: Phillip Wood <phillip.wood123@gmail.com>
To: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Cc: Tian Yuchen <a3205153416@gmail.com>,
	karthik.188@gmail.com,
	Johannes Schindelin <johannes.schindelin@gmx.de>
Subject: Re: [PATCH v11] setup: improve error diagnosis for invalid .git files
Date: Tue, 3 Mar 2026 19:31:04 +0000	[thread overview]
Message-ID: <460f00d5-97b4-4a6c-be45-6f60a17cd33e@gmail.com> (raw)
In-Reply-To: <xmqqjyvu42pw.fsf@gitster.g>

On 02/03/2026 16:26, Junio C Hamano wrote:
> Let's try again.
> 
> Can folks equipped with knowledge and environment to debug breakages
> that hapepns only on Windows lend a hand to figure out what this
> patch gets wrong to help the topic move forward?

Looking at the test failures the tests are failing because

     GIT_DIR=/dev/null git diff --no-index ...

which is used by test_cmp() on Windows is dying. That happens because 
stat("nul", &st) fails and this series makes that an error (somewhere 
along the line "/dev/null" is rewritten to "nul" on Windows). I'm afraid 
I don't know enough about Windows to be sure how to fix it but maybe we 
should special case "nul" in the setup code or mingw_stat(). We should 
also check what happens when GIT_DIR=/dev/null on linux and other POSIX 
platforms.

Thanks

Phillip


> Thanks.
> 
> Junio C Hamano <gitster@pobox.com> writes:
> 
>> 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_MISSING'(which groups the "file missing" scenarios
>>> together) and 'READ_GITFILE_ERR_IS_A_DIR'.
>>>
>>> To preserve the original intent of the setup process:
>>> 1. Update 'read_gitfile_error_die()' to treat both 'IS_A_DIR' and
>>>     'MISSING' as no-ops, while continuing to call 'die()' on true
>>>     'NOT_A_FILE' errors to prevent security hazards (like FIFOs).
>>> 2. Unconditionally pass '&error_code' to 'read_gitfile_gently()'.
>>> 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                       | 45 ++++++++++++++------
>>>   setup.h                       |  2 +
>>>   submodule.c                   |  2 +-
>>>   t/meson.build                 |  1 +
>>>   t/t0009-git-dir-validation.sh | 77 +++++++++++++++++++++++++++++++++++
>>>   worktree.c                    |  6 ++-
>>>   6 files changed, 118 insertions(+), 15 deletions(-)
>>>   create mode 100755 t/t0009-git-dir-validation.sh
>>
>> Unfortunately this seems to break almost all the tests, not just the
>> test the patch adds, on Windows (which I almost know nothing about,
>> but I can observe that CI jobs die).
>>
>> https://github.com/git/git/actions/runs/22464017037 is a CI run that
>> merged this patch on top of the commit that corresponds to the tip
>> of 'next' as of today.  We can see "win test (N)" jobs dying all
>> over.  I cancelled the workflow before seeing everything die,
>> though.
>>
>> https://github.com/git/git/actions/runs/22464479533 is a CI run that
>> tests this patch applied directly on v2.53.0 in isolation.
>>
>> As I said, I do not know Windows well, so this may be a red-herring,
>> but in this CI run, we see "GIT_DIR=/dev/null git diff --no-index ..."
>> results in "fatal: error reading 'nul'":
>>
>>    https://github.com/git/git/actions/runs/22464479533/job/65067515458#step:5:95419
>>
>> which is an expected thing to happen, but we probably used to ignore
>> it as a non-error?
>>
>> For now, I'll kick this topic out of my tree to give other topics a
>> bit more test exposure so that we can notice new bugs in them (not
>> in this topic) that causes the tests fail.  With this topic in 'seen',
>> such bugs in other topics are all masked.
>>
>>
>>
>> Thanks.
> 


  reply	other threads:[~2026-03-03 19:31 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
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 [this message]
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=460f00d5-97b4-4a6c-be45-6f60a17cd33e@gmail.com \
    --to=phillip.wood123@gmail.com \
    --cc=a3205153416@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=johannes.schindelin@gmx.de \
    --cc=karthik.188@gmail.com \
    --cc=phillip.wood@dunelm.org.uk \
    /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