Re: Odd Difference Between Windows Git and Standard Git

From: Torsten Bögershausen <tboegi@web.de>
Date: May 20, 2016, 16:12 UTC
Message-ID: <5067f10f-a12e-c6e6-493b-5ff14dae4380@web.de>
In-Reply-To: <xmqqy474g3cv.fsf@gitster.mtv.corp.google.com>

On 20.05.16 17:23, Junio C Hamano wrote:

Show 24 quoted lines

> Torsten Bögershausen <tboegi@web.de> 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;
	}