Problem with git and file mode changes

Problem with git and file mode changes

[Dani Moncayo]

Hello list,

I have installed an up-to-date version of Cygwin on a Windows 8.1
machine:

  $ uname -a
  CYGWIN_NT-6.3 LEG570 2.2.1(0.289/5/3) 2015-08-20 11:42 x86_64 Cygwin

I have a problem with git.  This is the installed version:

  $ git --version
  git version 2.5.1

After doing a 'git pull', I saw that git didn't make the merge,
because apparently I had some local changes.  But I didn't make
any local change.  For example, this file appears as modified:

  $ git status --short test/rmailmm.el
   M test/rmailmm.el

  $ git diff test/rmailmm.el
  diff --git a/test/rmailmm.el b/test/rmailmm.el
  old mode 100644
  new mode 100755

Mmm strange, I never changed the permissions of any file in my
repo.  And moreover:

  $ ls -o test/rmailmm.el
  -rwxrwxr--+ 1 Dani 3106 Sep 4 16:19 test/rmailmm.el

According to 'ls', the file mode is 774, but according to git is
755.  Which one is wrong?

Well, let's try to revert the misterious change:

  $ git checkout test/rmailmm.el

  $ git status --short test/rmailmm.el
   M test/rmailmm.el

  $ git diff test/rmailmm.el
  diff --git a/test/rmailmm.el b/test/rmailmm.el
  old mode 100644
  new mode 100755

  $ ls -o test/rmailmm.el
  -rwxrwxr--+ 1 Dani 3106 Sep  4 16:28 test/rmailmm.el

Apparently nothing has changed after the 'git checkout'!!

Do you know what's happening here?

TIA

-- 
Dani Moncayo

PS: keep my address CC'd, as I'm not subscribed to this list.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Problem with git and file mode changes

[Adam Dinwoodie]

On Fri, Sep 04, 2015 at 04:44:11PM +0200, Dani Moncayo wrote:
> After doing a 'git pull', I saw that git didn't make the merge,
> because apparently I had some local changes.  But I didn't make
> any local change.  For example, this file appears as modified:
> 
>   $ git status --short test/rmailmm.el
>    M test/rmailmm.el
> 
>   $ git diff test/rmailmm.el
>   diff --git a/test/rmailmm.el b/test/rmailmm.el
>   old mode 100644
>   new mode 100755
> 
> Mmm strange, I never changed the permissions of any file in my
> repo.  And moreover:
> 
>   $ ls -o test/rmailmm.el
>   -rwxrwxr--+ 1 Dani 3106 Sep 4 16:19 test/rmailmm.el
> 
> According to 'ls', the file mode is 774, but according to git is
> 755.  Which one is wrong?

Git internally only stores file permissions of 755 or 644*; anything
else is mapped down to one of those two, based (I believe) on whether
the user execute bit is set or not.

> Well, let's try to revert the misterious change:
> 
>   $ git checkout test/rmailmm.el
> 
>   $ git status --short test/rmailmm.el
>    M test/rmailmm.el
> 
>   $ git diff test/rmailmm.el
>   diff --git a/test/rmailmm.el b/test/rmailmm.el
>   old mode 100644
>   new mode 100755
> 
>   $ ls -o test/rmailmm.el
>   -rwxrwxr--+ 1 Dani 3106 Sep  4 16:28 test/rmailmm.el
> 
> Apparently nothing has changed after the 'git checkout'!!

It looks like the underlying file system is failing to record the file
permissions correctly**.  That could be a limitation of the file system
(FAT32 is much more limited than NTFS, for example, and I could believe
permissions go very wrong over network shares), of the options with
which the filesystem is mounted in Cygwin (take a look for "noacl" in
the Cygwin FAQs), or possibly just that you don't have permission to
change the file properties (although I'd expect an error in that
scenario).  Another option is that some non-Cygwin program is getting in
the way and interfering with the permissions.

The underlying problem here is that Cygwin is trying to write a file
without the executable bit set, but whenever it checks the filesystem,
it sees the executable bit is set, and so has to assume that's a change.
If you can't fix the filesystem, you can tell Git to ignore the
filesystem executable bit with

    git config --global --bool core.fileMode false

(Remove the `--global` to only change it for the current repository.)

If you do that, you'll need to use `git update-index` if you need to
change the executable bit as recorded in the Git repository; see `git
help update-index` under the `--chmod` option for details.

HTH

Adam

* There are some special values stored in the same way as permissions
to denote things like submodules or symlinks, but the above is correct
as far as simple files are concerned.

** Where by "correctly" I mean "in the POSIX-like style that Cygwin
understands and uses"; it probably is correct from a Windows
perspective.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Problem with git and file mode changes

[Ken Brown]

On 9/4/2015 11:12 AM, Adam Dinwoodie wrote:
> On Fri, Sep 04, 2015 at 04:44:11PM +0200, Dani Moncayo wrote:
>> After doing a 'git pull', I saw that git didn't make the merge,
>> because apparently I had some local changes.  But I didn't make
>> any local change.  For example, this file appears as modified:
>>
>>    $ git status --short test/rmailmm.el
>>     M test/rmailmm.el
>>
>>    $ git diff test/rmailmm.el
>>    diff --git a/test/rmailmm.el b/test/rmailmm.el
>>    old mode 100644
>>    new mode 100755
>>
>> Mmm strange, I never changed the permissions of any file in my
>> repo.  And moreover:
>>
>>    $ ls -o test/rmailmm.el
>>    -rwxrwxr--+ 1 Dani 3106 Sep 4 16:19 test/rmailmm.el
>>
>> According to 'ls', the file mode is 774, but according to git is
>> 755.  Which one is wrong?
>
> Git internally only stores file permissions of 755 or 644*; anything
> else is mapped down to one of those two, based (I believe) on whether
> the user execute bit is set or not.
>
>> Well, let's try to revert the misterious change:
>>
>>    $ git checkout test/rmailmm.el
>>
>>    $ git status --short test/rmailmm.el
>>     M test/rmailmm.el
>>
>>    $ git diff test/rmailmm.el
>>    diff --git a/test/rmailmm.el b/test/rmailmm.el
>>    old mode 100644
>>    new mode 100755
>>
>>    $ ls -o test/rmailmm.el
>>    -rwxrwxr--+ 1 Dani 3106 Sep  4 16:28 test/rmailmm.el
>>
>> Apparently nothing has changed after the 'git checkout'!!
>
> It looks like the underlying file system is failing to record the file
> permissions correctly**.  That could be a limitation of the file system
> (FAT32 is much more limited than NTFS, for example, and I could believe
> permissions go very wrong over network shares), of the options with
> which the filesystem is mounted in Cygwin (take a look for "noacl" in
> the Cygwin FAQs), or possibly just that you don't have permission to
> change the file properties (although I'd expect an error in that
> scenario).  Another option is that some non-Cygwin program is getting in
> the way and interfering with the permissions.

This could also be a result of default ACL entries on the directory 
'test'.  Dani, you might want to try 'setfacl -b test' and/or 'setfacl 
-k test'.  ('setfacl -h' will give you more information.)

Ken


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Problem with git and file mode changes

[Dani Moncayo]

Adam, Ken, thank you for taking time to help me.

(BTW, did you keep my address in CC?  Because I didn't get any of your
replies.  I had to check the mailing list web archive [1]).

BTW(2): For the record, some data points I forgot to give in my initial post:
* The underlying filesystem is NTFS.
* I did not have this problem some weeks ago, with the same
  system, Cygwin installation, and git repo.  Therefore, some
  change/update in my system/environment must have introduced the problem.

Ken's suggestion (setfacl -b test) didn't work, but it did work when I
executed it on individual files (eg. 'test/rmailmm.el' instead of
'test').  So the problem is apparently fixed after doing:

  find . -exec setfacl -b {} \;

Thank you so much.

-- 
Dani Moncayo

Footnotes:
[1] https://cygwin.com/ml/cygwin/2015-09/

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Problem with git and file mode changes

[Andrey Repin]

Greetings, Dani Moncayo!

> Adam, Ken, thank you for taking time to help me.

> (BTW, did you keep my address in CC?  Because I didn't get any of your
> replies.  I had to check the mailing list web archive [1]).

Per the very purpose of mailing list, you're expected to subscribe for
conversation.
You can't really expect people to go to the trouble of checking if they need
to send additional copies or not.

> BTW(2): For the record, some data points I forgot to give in my initial post:
> * The underlying filesystem is NTFS.
> * I did not have this problem some weeks ago, with the same
>   system, Cygwin installation, and git repo.  Therefore, some
>   change/update in my system/environment must have introduced the problem.

> Ken's suggestion (setfacl -b test) didn't work, but it did work when I
> executed it on individual files (eg. 'test/rmailmm.el' instead of
> 'test').  So the problem is apparently fixed after doing:

>   find . -exec setfacl -b {} \;

> Thank you so much.

The idea of resetting ACL's on the top-level directory is to have a clean
start with the checkout. Doing it on an already existing tree may not yield
desirable results… as you've discovered yourself.

And if you ask me, a VCS that trying to preserve exact access mask is just
asking for trouble.


-- 
With best regards,
Andrey Repin
Saturday, September 5, 2015 14:40:23

Sorry for my terrible english...

Mailing list CCing etiquette [Was: Problem with git and file mode changes]

[Adam Dinwoodie]

On Sat, Sep 05, 2015 at 12:13:51PM +0200, Dani Moncayo wrote:
> (BTW, did you keep my address in CC?  Because I didn't get any of your
> replies.  I had to check the mailing list web archive [1]).

Standard procedure on this list (which I think is different to most such
lists, but it's afaik what this list has always done) is to only CC
people if there's an explicit reason to assume they're not subscribed
(which normally means because they've said so).  Otherwise we just
assume they've subscribed to the list and will see responses that way.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple