On 20.05.16 17:23, Junio C Hamano wrote:
> Torsten Bögershausen <tboegi@xxxxxx> writes:
>
>>>> What does
>>>> git diff
>>>> say ?
>>>
>>> Great question. For all the unexpected files it says the
>>> same thing:
>>>
>>> old mode 100755
>>> new mode 100644
>>
>> So the solution is to run
>> git config core.filemode false
>
> Thanks for asking a great question. I somehow expected that we
> probe in init-db.c::create_default_files() for this when we probe
> for case sensitivity, symlinks, etc., but apparently we don't.
>
> I guess we don't because on some filesystems we can't. IIRC, it
> goes something like: chmod immediately followed by lstat pretends
> that change to the executable bit stuck, until the in-core buffer at
> the vfs layer is flushed to the disk platter that holds the
> filesystem without any notion of executable bit.
We do the probing, when the repo is cloned, and then never again.
If I clone the repo under Windows, the probing gives core.filemod false.
If I clone under Linux, the probing gives core.filemod true.
Unfortunatly Git for Windows looks at core.filemode, when looking
at the working tree, even if the stat() implementation never detects
the executable bit.
A fix could look like this:
static int git_default_core_config(const char *var, const char *value)
{
/* This needs a better name */
if (!strcmp(var, "core.filemode")) {
#ifndef GIT_WINDOWS_NATIVE
trust_executable_bit = git_config_bool(var, value);
#endif
return 0;
}
--
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