public inbox for git@vger.kernel.org
 help / color / mirror / Atom feed
From: Tian Yuchen <a3205153416@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, karthik.188@gmail.com
Subject: Re: [PATCH v5 2/2] setup: allow cwd/.git to be a symlink to a directory
Date: Thu, 19 Feb 2026 13:11:55 +0800	[thread overview]
Message-ID: <e370cace-1a43-444a-a3d1-5ea35dd22e60@gmail.com> (raw)
In-Reply-To: <xmqqtsvd7vu6.fsf@gitster.g>

On 2/19/26 02:25, Junio C Hamano wrote:
> Tian Yuchen <a3205153416@gmail.com> writes:
> 
>> Strictly enforcing 'lstat()' prevents valid '.git' symlinks.
> 
> But nobody sane would propose running one more lstat() anyway, so
> how is that relevant?
> 
>>   		if (!gitdirenv) {
>> -			if (die_on_error ||
>> -			    error_code == READ_GITFILE_ERR_NOT_A_FILE) {
>> -				/* NEEDSWORK: fail if .git is not file nor dir */
>> -				if (is_git_directory(dir->buf)) {
>> -					gitdirenv = DEFAULT_GIT_DIR_ENVIRONMENT;
>> -					gitdir_path = xstrdup(dir->buf);
>> -				}
>> -			} else if (error_code != READ_GITFILE_ERR_STAT_FAILED)
>> -				return GIT_DIR_INVALID_GITFILE;
> 
> The _intent_ of the original code was to
> 
>      * do is_git_directory() thing to deal with a plain vanilla
>        ".git" directory when read_gitfile_gently thing said "we found
>        a directory" (NOT_A_FILE is overly coarse, which is what we
>        are correcting in this topic, but the _intent_ was to do the
>        is_git_directory() thing when we know it is a directory).
> 
>      * return INVALID_GITFILE on any error, but do not return when
>        the reason why read_gitfile_gently thing failed was because
>        there is no ".git" there (again, STAT_FAILED is overly coarse,
>        which is what we are correcting in this topic, but the
>        _intent_ was to return INVALID thing when we not the failure
>        is not due to ENOENT).  Note that returning INVALID_GITFILE is
>        done when die_on_error is not set.
> 
>> -		} else
>> +			if (error_code)
>> +				read_gitfile_error_die(error_code, dir->buf, NULL);
> 
> Should this be unconditional?  If our caller did not ask us to die
> upon an error with die_on_error, what happens?  The original I think
> returned INVALID_GITFILE for the caller to deal with.
> 
>> +			if (is_git_directory(dir->buf)) {
> 
> Should this be unconditional?  If the thing is a directory, the
> original would have given us NOT_A_FILE but now it would give us
> IS_A_DIR.  And that is the only case original wanted to call
> is_git_directory() no?
> 
>> +				gitdirenv = DEFAULT_GIT_DIR_ENVIRONMENT;
>> +				gitdir_path = xstrdup(dir->buf);
>> +			}
>> +		} else {
>>   			gitfile = xstrdup(dir->buf);
>> +		}
>>   		/*
>>   		 * Earlier, we tentatively added DEFAULT_GIT_DIR_ENVIRONMENT
>>   		 * to check that directory for a repository.


Thanks for the review.

I have already sent out v6 yesterday. Here is the link:

https://lore.kernel.org/git/20260218124638.176936-1-a3205153416@gmail.com/

Based on your feedback and the changes that have been made on v6, it 
seems that the tasks that need to be completed are as follows:

  - Conditional 'is_git_directory' check: restrict the 
'is_git_directory()' check to only run when we explicitly get 
'READ_GITFILE_ERR_IS_A_DIR'. It makes no sense to check it for other 
error types.

  - Squash two patches into one single commit, as you suggested. 
(Actually, I'm a bit confused—are you saying to “make both patches 
standalone executable” or to “merge the two patches directly”? Either 
way, I'll go ahead and send the v7 patches first.)

  - Rephrase the commit message to describe the lstat() limitation, 
rather than saying 'we switch to stat()'

The holiday is over, and my efficiency in sending patches and replying 
to emails may be somewhat reduced. Please bear with me.

Regards,

Yuchen

  reply	other threads:[~2026-02-19  5:12 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-11 18:21 [RFC] setup: fail if .git is not a file or directory Tian Yuchen
2026-02-11 19:47 ` Junio C Hamano
2026-02-12 17:33   ` Tian Yuchen
2026-02-12 17:24 ` [PATCH v2] " Tian Yuchen
2026-02-12 20:59   ` Junio C Hamano
2026-02-13 16:37     ` Tian Yuchen
2026-02-14  4:52   ` [PATCH v3] " Tian Yuchen
2026-02-15  8:41     ` Junio C Hamano
2026-02-15 16:22       ` Tian Yuchen
2026-02-16  2:37         ` Junio C Hamano
2026-02-16 16:02           ` Tian Yuchen
2026-02-17  8:41             ` [PATCH v4] setup: allow cwd/.git to be a symlink to a directory Tian Yuchen
2026-02-17 11:26               ` Karthik Nayak
2026-02-17 15:30                 ` Tian Yuchen
2026-02-17 18:56                   ` Karthik Nayak
2026-02-17 21:10                     ` Junio C Hamano
2026-02-17 17:01                 ` Junio C Hamano
2026-02-17 18:50                   ` Karthik Nayak
2026-02-18  4:08                     ` Tian Yuchen
2026-02-17 17:59               ` Karthik Nayak
2026-02-18  5:18               ` [PATCH v5 0/2] setup.c: v5 reroll Tian Yuchen
2026-02-18  5:18                 ` [PATCH v5 1/2] setup: distingush ENOENT from other stat errors Tian Yuchen
2026-02-18 10:12                   ` Karthik Nayak
2026-02-18 11:11                     ` Tian Yuchen
2026-02-18 18:15                   ` Junio C Hamano
2026-02-18 18:43                     ` Junio C Hamano
2026-02-18  5:18                 ` [PATCH v5 2/2] setup: allow cwd/.git to be a symlink to a directory Tian Yuchen
2026-02-18 10:27                   ` Karthik Nayak
2026-02-18 11:20                     ` Tian Yuchen
2026-02-18 18:25                   ` Junio C Hamano
2026-02-19  5:11                     ` Tian Yuchen [this message]
2026-02-15 17:08       ` [PATCH v3] setup: fail if .git is not a file or directory Tian Yuchen
2026-02-12 22:39 ` [RFC] " brian m. carlson
2026-02-12 22:45   ` Junio C Hamano
2026-02-12 23:03     ` brian m. carlson

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=e370cace-1a43-444a-a3d1-5ea35dd22e60@gmail.com \
    --to=a3205153416@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=karthik.188@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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