Re: Odd Difference Between Windows Git and Standard Git

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:

>> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]