Re: Odd Difference Between Windows Git and Standard Git

From: Junio C Hamano <gitster@pobox.com>
Date: May 23, 2016, 18:52 UTC
Message-ID: <xmqqeg8sa9oq.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <alpine.DEB.2.20.1605231310190.4122@virtualbox>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 15 quoted lines

>> Of course, if you are doing network mount between systems with and
>> without filemode support, the result would depend on where you did
>> the "git init", so that would not help.
>> 
>> Which means that other probed things like symlink support and case
>> sensitivity are likely to be wrong in the .git/config that the user
>> may want to fix.
>
> What we could do is to make the default config setting platform-dependent,
> a la CRLF_NATIVE.
>
> I imagine that we would want this for core.filemode, core.ignorecase and
> core.symlinks.
>
> What do you think?

The reason why we probe for filemode, icase, etc. at repository creation time and record the result in the configuration is because we do not to want to do the auto-probing at runtime, every time we run any Git command. You may be able to say "On this platform, no matter what filesystem is in use, you will always get icase and you will never have executable bit", and a build on such a platform can hardcode these three values. But on other platforms these may be per-filesystem properties, and their binaries would not be able to hardcode the choices, which would mean we would record these three in .git/config on these platforms when a repository is created.

Git built for Windows may have core.filemode=false as "the default config setting platform-dependent, a la CRLF_NATIVE"; how would that interact with a configured core.filemode value in .git/config?

If a repository that is initialized on a non Windows system is network mounted or rsynced and made available on Windows, its .git/config would record values that are suitable for the origin platform (and the filesystem the repository was originally on). On Windows where you can declare "no case sensitivity, no symlink and no executable bits", a solution would be to ignore these three configurable values and always use hardcoded values. Everything would work without the end user even having to know what is going on.

But that would not be a good approach other platforms can follow to solve the same issue. A repository created on ext4 may be rsynced into a case sensitive HFS+ or a case insensitive one. MacOS X side needs to have some way to tell what value for core.ignorecase to use between these two cases, as its binary cannot hardcode "no case sensitivity".

So,... I am not enthused.