Subject: Re: [PATCH v5 1/2] setup: distingush ENOENT from other stat errors

From: Junio C Hamano <[email-masked]>
Date: Wed, 18 Feb 2026 10:43:28 -0800

Junio C Hamano <[email-masked]> writes:

> Tian Yuchen <[email-masked]> writes:
>
>> Currently, 'read_gitfile_gently()' treats all 'stat()' failures as
>> generic errors. This prevents distinguishing between a missing file and
>> real errors like permission denied (fatal).
>
> The above plan makes sense---you would split stat() error into two
> different classes, start returning ERR_STAT_NOENT in addition to
> ERR_STAT_FAILED, have the caller act on the new ERR_STAT_NOENT and
> adjust the way it acts on ERR_STAT_FAILED, and if possible add tests
> to make sure we react to failures from stat in an appropriate way
> (but how? --- it is where my "if possible" comes from).  So I would
> expect that the other patch would be to split ERR_NOT_A_FILE and add
> ERR_IS_A_DIR, have the caller act on the new ERR_IS_A_DIR and adjust
> the way it acts on ERR_NOT_A_FILE.

I forgot to say one thing.

When changing the external interface for these service functions
like read_gitfile_gently() and read_gitfile_error_die(), we need to
make sure the change will not break _other_ callers of them, outside
our main focus area.  The latter, for example, has a caller in
submodule.c and we need to make sure that the existing code is
reacting to the updated definition of what ERR_STAT_FAILED and
ERR_NOT_A_FILE mean (and if not, adjust it).  read_gitfile_gently()
is used more widely outside setup.c and we need to audit these
callers, too.