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

From: Tian Yuchen <a3205153416@gmail.com>
Date: Mar 4, 2026, 18:41 UTC
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.

Show 7 quoted lines

> 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.

Show 10 quoted lines

> 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.

Show 33 quoted lines

> 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