From: Tian Yuchen <a3205153416@gmail•com>
To: Junio C Hamano <gitster@pobox•com>
Cc: Phillip Wood <phillip.wood123@gmail•com>,
git@vger•kernel.org, karthik.188@gmail•com,
Johannes Schindelin <johannes.schindelin@gmx•de>
Subject: Re: [PATCH v11] setup: improve error diagnosis for invalid .git files
Date: Thu, 5 Mar 2026 02:41:46 +0800 [thread overview]
Message-ID: <00f6d468-7d00-4edc-886d-723322420539@gmail.com> (raw)
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
next prev parent reply other threads:[~2026-03-04 18:41 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
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 [this message]
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=00f6d468-7d00-4edc-886d-723322420539@gmail.com \
--to=a3205153416@gmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
--cc=johannes.schindelin@gmx$(echo .)de \
--cc=karthik.188@gmail$(echo .)com \
--cc=phillip.wood123@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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