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

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 18, 2026, 18:15 UTC
Message-ID: <xmqqy0kp7wai.fsf@gitster.g>
In-Reply-To: <20260218051850.164972-2-a3205153416@gmail.com>

Tian Yuchen <a3205153416@gmail.com> 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.

But then the proposed log message below says that in addition to NOENT, it also deals with IS_A_DIR. I do not mind doing these two in the same patch, but I do prefer to see each patch to be complete. If a callee is changed and starts returning different return values, the callers must be also adjusted to react to these new return values.

Looking at the preimage of [v5 2/2], we stil check if dir->buf is a plain vanilla ".git" directory only when read_gitfile_gently() returns ERR_NOT_A_FILE with [v5 1/2] applied, but in the new world order with this patch applied, shouldn't the caller deal with ".git" when it gets ERR_IS_A_DIR and not ERR_NOT_A_FILE?

After applying this patch but before applying [v5 2/2], we lose the ability to use plain vanilla ".git"? That is the kind of thing I meant by each patch to be complete.

So, I do not understand what the splitting the topic into two along this axis is trying to achieve.

Thanks.