On 05/23/2016 08:52 PM, Junio C Hamano wrote:
Johannes Schindelin <johannes.schinde...@gmx.de> 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 core.filemode is true, Git for Windows could:
a) Behave as today, report changed files (filemode)
b) Give warning to the user (and report changed filemode)
c) Error out, saying misconfigured worktree
d) use core.filemode = false anyway.
e) Give a warning and use core.filemode = false anyway.
At the moment I tend for c), as it makes it clear what is going wrong,
what do you think ?
[skip ignorecase for a second]
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
