From: Tian Yuchen <a3205153416@gmail.com>
Date: Wed, 04 Mar 2026 18:41:46 GMT
Subject: Re: [PATCH v11] setup: improve error diagnosis for invalid .git files
Message-ID: <00f6d468-7d00-4edc-886d-723322420539@gmail.com>
In-Reply-To: <xmqqcy1j8o5r.fsf@gitster.g>

Hi Junio,

On 3/5/26 02:06, Junio C Hamano wrote:

> v12 does work differently from what we have been aiming for, but I
> find that it arguably is a much safer approach.

Maybe, but my main concern was that adding 'die()' in 
'setup_git_directory_gently_1()' might not be the best choice. 
Considering the implementations of the preceding functions, I though 
locating 'die()' in 'setup_explicit_git_dir()' might be a better choice? 
By the way, I noticed there's a '(read_gitfile(path))' macro that 
expands to 'read_gitfile(path, NULL)'. I was planning to pass 
'error_code' here, essentially moving the logic from the original 
'setup_git_directory_gently_1()' to this location, where the former 
would only be responsible for returning the error status... The changes 
would be a bit too extensive if I did it that way.

Since you say the v12 patch is safer, I have no objections. I'm 
completely unsure about the overall structure of this part. Skill issue.

> Even though the updated read_gitfile_gently() returns finer-grained
> READ_GITFILE_ERR_* codes than the original, read_gitfile_error_die()
> does not change behaviour from the original.  Any caller that use
> read_gitfile(path), which is read_gitfile_gently(path, NULL), like
> the setup_explicit_git_dir() codepath we have been looking at lately,
> lets read_gitfile_error_die() react to the error code, which is to
> behave exactly as what the code did before this patch.

I should have considered this. I feel that the changes in v12 are 
actually more like a band-aid fix compared to the previous ones.

You mentioned this change didn't touch 'read_gitfile_error_die()', and I 
think that's one of the benefits of such simple modifications. I just 
can't be entirely sure what the trade-offs might be — perhaps it's my 
lack of experience, but I always worry about digging a deep hole for 
future developers to fill. I'll keep learning.

> So, I dunno.  After all, these two NEEDSWORK comments have been with
> us for quite some time, and reminded us that we may want to consider
> if we need to do anything differently.  I do not think we mind if we
> conclude negatively, taking "no, it is of dubious value to tighten
> error checking in these code paths" as an answer to these NEEDSWORK
> comments.  v12 is slightly less defeatest than that stance in that
> we are only allowing the callers that care about what kind of errors
> they are getting and and want to decide how to react to them, while
> keeping the default error behaviour the same for those who do not
> ask with &error_code what kind of errors we saw.

I see.

> The patch makes the behaviour change for callers that pass an
> &error_code pointer to read_gitfile_gently() and act on the returned
> error code itself, like the discovery code path.  As long as these
> callers are audited and adjusted as necessary, we have very little
> risk of regression.
> 
> I won't be doing a full audit in this message, but just to give
> taste of what is expected ...
> 
> $ git grep -n -e 'read_gitfile_gently('
> 
> builtin/init-db.c:212:		p = read_gitfile_gently(git_dir, &err);
> 
> This caller gives &err but it never looks at what is in it after the
> call returns, so there shouldn't be any behaviour change.
> 
> setup.c:465:	if (read_gitfile_gently(path->buf, &gitfile_error) || is_git_directory(path->buf))
> 
> This is followed by
> 
> 		ret = 1;
>          if (gitfile_error == READ_GITFILE_ERR_OPEN_FAILED ||
>              gitfile_error == READ_GITFILE_ERR_READ_FAILED)
>                  ret = 1;
> 
> I do not offhand know if this list of "error codes that should
> result in returning 1 from this function" needs to be tweaked to
> adjust for the change in this patch.
> 
> worktree.c:390:	path = xstrdup_or_null(read_gitfile_gently(wt_path.buf, &err));
> 
> This is followed by code that reacts to path being NULL and shows
> the contents of err in an error message.  Should be benign.

I don't think this needs to be changed. If a new error_code 
READ_GITFILE_MISSING is encountered, then this isn't a repository at 
all, so it won't enter the if statement, and ret = 0.

If encountering the READ_GITFILE_ERR_IS_A_DIR, the 
is_git_directory(path->buf) check takes precedence. If it detects a 
valid .git directory, it returns 1. Therefore, the gitfile_error 
function doesn't need to match IS_A_DIR at all.

Thank you for taking the time to review my (roughly made) patch.

Goodnight,

Yuchen