Odd Difference Between Windows Git and Standard Git

Odd Difference Between Windows Git and Standard Git

[Jon Forrest]

I'm running Git version 2.8.2 built from source on Ubuntu 16.04.
I'm using a repository that's stored on Dropbox. I'm the only person
accessing this repo. Everything works great.

For reasons unrelated to Git, I decided to try Git for Windows,
so I installed "git version 2.8.2.windows.1" on Windows 10.
When I run 'git status' on Ubuntu the list I see is exactly what
I expect. However, when I run 'git status' on the
same Dropbox repo on Windows, I see what I expect plus I'm told
that every .pdf file and some .png files are modified.

I'm guessing that this is caused by some mishandling of
binary files. Is this behavior to be expected? If so, is there
something I can do to have the output on Windows be the
same as on Ubuntu? I'm aware of 'git update-index --assume-unchanged'
but this seems harsh.

I copied the repo to a non-Dropbox location, just in case
it was Dropbox that was causing the problem, but this didn't
make any difference.

(If you want to try this yourself, try it on the ProGit2
book source on Github).

Thanks,
Jon Forrest

Re: Odd Difference Between Windows Git and Standard Git

[Torsten Bögershausen]

On 20.05.16 03:48, Jon Forrest wrote:
> I'm running Git version 2.8.2 built from source on Ubuntu 16.04.
> I'm using a repository that's stored on Dropbox. I'm the only person
> accessing this repo. Everything works great.
> 
> For reasons unrelated to Git, I decided to try Git for Windows,
> so I installed "git version 2.8.2.windows.1" on Windows 10.
> When I run 'git status' on Ubuntu the list I see is exactly what
> I expect. However, when I run 'git status' on the
> same Dropbox repo on Windows, I see what I expect plus I'm told
> that every .pdf file and some .png files are modified.
To bring at least a little light into the story:

What does 
git diff
say ?

What does 
git config -l | grep core
say ?

And what does
git ls-files --eol
say?

Re: Odd Difference Between Windows Git and Standard Git

[Jon Forrest]

On 5/20/2016 6:19 AM, Torsten Bögershausen wrote:
> On 20.05.16 03:48, Jon Forrest wrote:
>> I'm running Git version 2.8.2 built from source on Ubuntu 16.04.
>> I'm using a repository that's stored on Dropbox. I'm the only person
>> accessing this repo. Everything works great.
>>
>> For reasons unrelated to Git, I decided to try Git for Windows,
>> so I installed "git version 2.8.2.windows.1" on Windows 10.
>> When I run 'git status' on Ubuntu the list I see is exactly what
>> I expect. However, when I run 'git status' on the
>> same Dropbox repo on Windows, I see what I expect plus I'm told
>> that every .pdf file and some .png files are modified.
> To bring at least a little light into the story:
>
> What does
> git diff
> say ?

Great question. For all the unexpected files it says the
same thing:

old mode 100755
new mode 100644

> What does
> git config -l | grep core
> say ?

core.symlinks=false
core.autocrlf=true
core.fscache=true
core.editor=vim
core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true
>
> And what does
> git ls-files --eol
> say?

The same thing for all the unexpected files,
which is:

i/-text w/-text attr/

I'm running the above commands on Windows.

The result of the 2nd question on Ubuntu is:

core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true

and the 3rd (for the expected files) is:

i/lf    w/lf    attr/

Jon

Re: Odd Difference Between Windows Git and Standard Git

[Torsten Bögershausen]

On 20.05.16 15:48, Jon Forrest wrote:
> 
> 
> On 5/20/2016 6:19 AM, Torsten Bögershausen wrote:
>> On 20.05.16 03:48, Jon Forrest wrote:
>>> I'm running Git version 2.8.2 built from source on Ubuntu 16.04.
>>> I'm using a repository that's stored on Dropbox. I'm the only person
>>> accessing this repo. Everything works great.
>>>
>>> For reasons unrelated to Git, I decided to try Git for Windows,
>>> so I installed "git version 2.8.2.windows.1" on Windows 10.
>>> When I run 'git status' on Ubuntu the list I see is exactly what
>>> I expect. However, when I run 'git status' on the
>>> same Dropbox repo on Windows, I see what I expect plus I'm told
>>> that every .pdf file and some .png files are modified.
>> To bring at least a little light into the story:
>>
>> 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

Re: Odd Difference Between Windows Git and Standard Git

[Jon Forrest]

On 5/20/2016 7:19 AM, Torsten Bögershausen wrote:

>> 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

This worked perfectly!

I wonder if this should be the default for Git for Windows.

Thanks for the quick (and correct) response.

Jon Forrest

Re: Odd Difference Between Windows Git and Standard Git

[Junio C Hamano]

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.

Re: Odd Difference Between Windows Git and Standard Git

[Torsten Bögershausen]

On 20.05.16 16:28, Jon Forrest wrote:
> 
> 
> On 5/20/2016 7:19 AM, Torsten Bögershausen wrote:
> 
>>> 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
> 
> This worked perfectly!
> 
> I wonder if this should be the default for Git for Windows.

It is.
But you need to clone the repo under Windows.

I probably submit a patch some day, that core.filemode will be ignored
under Windows.

Re: Odd Difference Between Windows Git and Standard Git

[Torsten Bögershausen]

On 20.05.16 17:23, Junio C Hamano wrote:
> 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;
	}

Re: Odd Difference Between Windows Git and Standard Git

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> 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.

Ah, we do probe by using "config" as a guinea pig file.

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.

Re: Odd Difference Between Windows Git and Standard Git

[Johannes Schindelin]

Hi,

On Fri, 20 May 2016, Junio C Hamano wrote:

> Junio C Hamano <gitster@pobox.com> writes:
> 
> > 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.
> 
> Ah, we do probe by using "config" as a guinea pig file.
> 
> 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?

Ciao,
Johannes

Re: Odd Difference Between Windows Git and Standard Git

[Jon Forrest]

On 5/23/2016 4:12 AM, Johannes Schindelin wrote:

> 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?

Would this change have any bad effects when the same repo is shared
by both Windows and *nix Git users over Dropbox or a shared filesystem?

Jon Forrest

Re: Odd Difference Between Windows Git and Standard Git

[Johannes Schindelin]

Hi Jon,

On Mon, 23 May 2016, Jon Forrest wrote:

> On 5/23/2016 4:12 AM, Johannes Schindelin wrote:
> 
> > 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?
> 
> Would this change have any bad effects when the same repo is shared
> by both Windows and *nix Git users over Dropbox or a shared filesystem?

Yes, if you have symbolic links in that repository. Likewise, if you have
users who find it funny to add different files whose names only differ in
their case, say, xt_DSCP.c and xt_dscp.c.

Also, if your Windows users want to add scripts, they will most likely not
mark them executable and your Linux users will call them names (forgetting
that they know just as little about the other platform as the developers
they try to ridicule).

Lots of fun things to keep in mind when sharing the same working directory
between Operating Systems.

But you said "when the same repo is shared"? Do you really mean the
*repository*? If so, there is not a problem. Only if you add a working
directory into the mix.

Ciao,
Johannes

Re: Odd Difference Between Windows Git and Standard Git

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@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 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.

Re: Odd Difference Between Windows Git and Standard Git

[Torsten Bögershausen]

On 05/23/2016 08:52 PM, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@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]

Re: Odd Difference Between Windows Git and Standard Git

[Johannes Schindelin]

[-- Attachment #1: Type: text/plain, Size: 2000 bytes --]

Hi,

On Tue, 24 May 2016, Torsten Bögershausen wrote:

> On 05/23/2016 08:52 PM, Junio C Hamano wrote:
> > Johannes Schindelin <Johannes.Schindelin@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.

Right, I missed this of course. My idea was to have saner defaults *iff
the config variables are not set explicitly*. But they *are* set, of
course. Just not in a way that makes sense when the very same working
directory is accessed from different Operating Systems.

> 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 ?

The problem with that is that we would need to probe again. Or dictate for
all eternity that Git for Windows cannot determine the executable bit (but
who knows for certain?)

I am pretty convinced that we should go with a)

Ciao,
Dscho

Re: Odd Difference Between Windows Git and Standard Git

[Torsten Bögershausen]

On 05/24/2016 01:57 PM, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 24 May 2016, Torsten Bögershausen wrote:
>
>> On 05/23/2016 08:52 PM, Junio C Hamano wrote:
>>> Johannes Schindelin <Johannes.Schindelin@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.
> Right, I missed this of course. My idea was to have saner defaults *iff
> the config variables are not set explicitly*. But they *are* set, of
> course. Just not in a way that makes sense when the very same working
> directory is accessed from different Operating Systems.
>
>> 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 ?
> The problem with that is that we would need to probe again.
The probing for the filemode:
Wouldn't it be enough to run lstat() on .git/ ?
If the user-execuatable bit is not set, but core.filemode is true, error 
out ?
That would not cost too much.
>   Or dictate for
> all eternity that Git for Windows cannot determine the executable bit (but
> who knows for certain?)
Can we can limit the eternity until the day when Windows can determine 
the executable
bit ?

Re: Odd Difference Between Windows Git and Standard Git

[Johannes Schindelin]

[-- Attachment #1: Type: text/plain, Size: 1622 bytes --]

Hi Torsten,

On Wed, 25 May 2016, Torsten Bögershausen wrote:

> On 05/24/2016 01:57 PM, Johannes Schindelin wrote:
> >
> > On Tue, 24 May 2016, Torsten Bögershausen wrote:
> >
> > > 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 ?
> >
> > The problem with that is that we would need to probe again.
>
> The probing for the filemode:
> Wouldn't it be enough to run lstat() on .git/ ?

What about `git diff --no-index`? There is no `.git/` to probe there.

> If the user-execuatable bit is not set, but core.filemode is true, error
> out ?  That would not cost too much.

I think it would cost us a nice and clean logic ;-)

> > Or dictate for all eternity that Git for Windows cannot determine the
> > executable bit (but who knows for certain?)
>
> Can we can limit the eternity until the day when Windows can determine
> the executable bit ?

The point is: I will have forgotten by next week what we talked about
(there are way too many things going on in my life), and if and when
compat/mingw.c will be taught to infer the executable bit, I am prone to
forget that warning (if we introduce it).

Therefore, out of entirely practical considerations, I favor the status
quo.

Ciao,
Dscho