Re: [PATCH] init: don't reset core.filemode on git-new-workdirs.

From: Madhu <enometh@meer.net>
Date: Mar 23, 2021, 03:57 UTC
Message-ID: <20210323.092748.1559327071188512317.enometh@meer.net>
In-Reply-To: <xmqqr1k76p8d.fsf@gitster.g>

*  Junio C Hamano <gitster@pobox.com> <xmqqr1k76p8d.fsf@gitster.g>
Wrote on Mon, 22 Mar 2021 11:02:42 -0700

Show 9 quoted lines

>> I don't think the posted patch (snipped) would work as reinit is
>> always 1 and we are always a candidate for reiniting - I may be
>> missing something.
>
> In other words, yes, the illustration patch you are responding to
> assumes that the "reinit" variable is set correctly (i.e. the HEAD
> exists and sensibly readable if you run "git init" in an already
> functioning working tree) and we can use it to avoid the filemode
> check.

Ah yes indeed.

Show 9 quoted lines

>> Using a new file for the filemode test would be a natural
>> improvement.
>
> That becomes necessary only if we want to futz with core.filemode
> while doing "reinit", as .git/config can be a symlink.  When we are
> creating a repository from scratch, we always create a regular file
> to prepare .git/config, and there is no need to do that, if we are
> happy to set core.filemode the same way as core.symlinks, i.e. only
> check once when the repository is created.  No?

Avoiding the filemode check completely during reinit is ok with me because it gave me wrong results. I can't speak for the original author of the code - if his intention was to do it explicitly as part of "reinitialization".

[In the latter case personally I'd want to edit the config file by hand in response to a message from git - and I certainly do not want git to change the config file behind my back without informing me.]

Thanks again.