git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Madhu <enometh@meer.net>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] init: don't reset core.filemode on git-new-workdirs.
Date: Sun, 21 Mar 2021 14:58:16 -0700	[thread overview]
Message-ID: <xmqq1rc89nk7.fsf@gitster.g> (raw)
In-Reply-To: <20210321.175821.1385189088303987287.enometh@meer.net> (Madhu's message of "Sun, 21 Mar 2021 17:58:21 +0530 (IST)")

Madhu <enometh@meer.net> writes:

> From: Madhu <enometh@net.meer>
>
> If the .git/config file is a symlink (as is the case of a .git created
> by the contrib/workdir/git-new-workdir script) then the filemode tests
> fail, and the filemode is reset to be false.  To avoid this only munge
> core.filemode if .git/config is a regular file.

Hmph, what's the sequence of events?  You let "git new-workdir" to
create a cheap copy of a working tree and then?  When new-workdir
returns, you already have a functional working tree with .git/
directory (in which there are many symbolic links).  So who wants or
needs to run "git init" there in the directory in the first place?

Is the problem being solved that running an unnecessary "git init"
in an already initialized repository does an unnecessary filemode
check?

If that is the case, I am not sure if asking "is it a symlink?" to
avoid the filemode trustability check is a good approach.  At that
point in the code you are patching, we have already determined if we
are running the "git init" in an already initialized repository
(i.e. "reinit"), so shouldn't we be basing the decision on it
instead?

I see that in a later part of the same function, we test if the
filesystem supports symbolic links but do so only when we are
running "git init" afresh.  Perhaps the filemode trustability check
and the config-set to record core.filemode should all be moved there
inside the "if (!reinit)" block.

All of the above assumes that the problem being solved is about what
happens when "git init" is run in an already functioning working
tree.  If I misread what problem you are trying to solve, then none
of what I suggested in the above may apply.

> ---
>  builtin/init-db.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

Missing sign-off; please review Documentation/SubmittingPatches


> diff --git a/builtin/init-db.c b/builtin/init-db.c
> index dcc45bef51..b053107336 100644
> --- a/builtin/init-db.c
> +++ b/builtin/init-db.c
> @@ -285,7 +285,8 @@ static int create_default_files(const char *template_path,
>  	/* Check filemode trustability */
>  	path = git_path_buf(&buf, "config");
>  	filemode = TEST_FILEMODE;
> -	if (TEST_FILEMODE && !lstat(path, &st1)) {
> +	if (TEST_FILEMODE && !lstat(path, &st1)
> +	    && (st1.st_mode & S_IFMT) == S_IFREG) {
>  		struct stat st2;
>  		filemode = (!chmod(path, st1.st_mode ^ S_IXUSR) &&
>  				!lstat(path, &st2) &&

  reply	other threads:[~2021-03-21 21:59 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-21 12:28 [PATCH] init: don't reset core.filemode on git-new-workdirs Madhu
2021-03-21 21:58 ` Junio C Hamano [this message]
2021-03-22  2:40   ` Madhu
2021-03-22  4:53     ` Junio C Hamano
2021-03-22  9:04       ` Madhu
2021-03-22 18:02         ` Junio C Hamano
2021-03-23  3:57           ` Madhu
2021-03-23  6:39             ` Junio C Hamano
2021-03-23 16:53               ` Torsten Bögershausen
2021-03-23 17:45                 ` Junio C Hamano
2021-03-23 20:31                   ` Torsten Bögershausen
2021-03-23 20:50                     ` Junio C Hamano
2021-06-18  4:18               ` Madhu

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqq1rc89nk7.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=enometh@meer.net \
    --cc=git@vger.kernel.org \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).