Git: file mode (file permission) is not respected

[nautilus7]

• [x] I was not able to find an open or closed issue matching what I'm seeing

Setup

• Which version of Git for Windows are you using? Is it 32-bit or 64-bit?

$ git --version --build-options

git version 2.20.1.windows.1
cpu: x86_64
built from commit: 7c9fbc07db0e2939b36095df45864b8cda19b64f
sizeof-long: 4
sizeof-size_t: 8

• Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?

$ cmd.exe /c ver

Microsoft Windows [Version 10.0.17763.195]

• What options did you set as part of the installation? Or did you choose the
  defaults?

# One of the following:
> type "C:\Program Files\Git\etc\install-options.txt"
> type "C:\Program Files (x86)\Git\etc\install-options.txt"
> type "%USERPROFILE%\AppData\Local\Programs\Git\etc\install-options.txt"
$ cat /etc/install-options.txt

Editor Option: VisualStudioCodeInsiders
Custom Editor Path: 
Path Option: Cmd
SSH Option: OpenSSH
CURL Option: OpenSSL
CRLF Option: CRLFCommitAsIs
Bash Terminal Option: MinTTY
Performance Tweaks FSCache: Enabled
Use Credential Manager: Enabled
Enable Symlinks: Disabled

• Any other interesting things about your environment that might be related
  to the issue you're seeing?

I have WSL (windows subsystem for linux) installed, but the issue I have is outside of WSL.

Details

• Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

MINGW64

• What commands did you run to trigger this issue? If you can provide a
  Minimal, Complete, and Verifiable example
  this will help us understand the issue.

** insert your commands here **

• What did you expect to occur after running these commands?

* insert here *

• What actually happened instead?

The issue I have is related to the file mode (755) for executable files...
I am working on a linux git repo from windows 10. The repo contains some .sh files (executables).

When I set the "filemode = true" option in the git repo config, I always see the following:

If I change the file mode back to 755, commit the changes and push to the online repo (github), the files there will have the correct (755) mode.

But the next time I open the "git gui" application, the file mode for all files is changed again to 644 and I see the same thing as in the photo above. If I choose to "revert changes" it doesn't do anything. The file mode remains changed.

I tried commands like:

git update-index --chmod=+x config.sh
git add --chmod=+x config.sh

but I had no success. Git has all .sh files in my repo listed with 755 mode. I confirmed with the following command:

git ls-files --stage

Setting git to ignore the file mode changes (by setting "filemode = false" in the config) is not a solution because when I want to make changes to the content of these executable files, they will committed with their mode (permissions) changed as well.

So, how can I make git to ACTUALLY remember the file mode???

• If the problem was occurring with a specific repository, can you provide the
  URL to that repository to help us with testing?

* insert URL here *

[PhilipOakley]

On Windows, don't change the filemode settings from the discovered true setting.

Windows does not have the Linux file modes, so the Git setting must always be done via the index record.

[tboegi]

On Windows, don't change the filemode settings from the discovered true setting.
Should that be:
On Windows, set core.file.mode false.
https://git-scm.com/docs/git-config

[nautilus7]

It was set to false initially, but after doing changes to one executable file, its filemode changed to 644, so I had to set it back to 755 with another commit.

Now, I edited this file again and the file mode didn't changed to 644. It stayed as it was (755), so everything is good.

Will see in the future... Thanks.

[PhilipOakley]

Just to say that Git itself does not store all the bits, only those that matter. Have a check of the manuals.

https://git-scm.com/docs/git-config#git-config-corefileMode

https://github.com/git/git/blob/master/Documentation/technical/index-format.txt L71-72

9-bit unix permission. Only 0755 and 0644 are valid for regular files. 
Symbolic links and gitlinks have value 0 in this field. 

[nautilus7]

Again, I made changes to the same executable via my editor (vscode) and the file mode was changed back to 644.

This time the change did not come directly from my editor, as the previous one that went fine.
This time, I was merging a branch into my master branch, and due to a conflict I had to edit the file in my editor during the process of merging. And this time the file mode changed back to 644.

I was able to set the mode back to 755 using git update-index --chmod=+x config.sh and committing.

All this time git was/is set to ignore permission changes... Any clue? Do I have to change the file mode back to 755 every time I edit my file? Thanks!

[tboegi]

git ls-files -s ## will show how git recorded the file (config.sh in your case)
## and if it will be executable (100755)
## once you commited, pushed and pulled into a real Linux/Unix/MacOS system
## This is important to maintain, and that is what you did, right?

ls ## will show what the file system has.
## under Git For Windows you will not see the x-bit set - that is OK

[nautilus7]

I am not sure I follow you...

1. The file had 755 mode and it was in a github repo.
2. The file was edited from another person (in another system, perhaps linux, I don't know, but I suppose so) and the changes were committed to github.
3. Then I pulled the changes to my local copy on a windows machine and I begun merging with another branch. During the merging process I had to edit the file in my editor (vscode) due to some conflicts. I resolved the conflict, I saved the file and I completed the merging.
4. I finally pushed the file to github and I realized that the mode was changed back to 644.

All this time my git installation is set to ignore file mode changes. So how does git ignore file mode changes if it's acting like this?

[dscho]

3\. Then I pulled the changes to my local copy on a windows machine and I begun merging with another branch. During the merging process I had to edit the file in my editor (vscode) due to some conflicts. I resolved the conflict, I saved the file and I completed the merging.

That most likely means that the file was added by the merged branch, that you at some stage did the equivalent of git reset (i.e. removed the entry from Git's index) and then added the file with git add (and because you have core.fileMode = false, that git add staged the "new" file with 100644).

[nautilus7]

I see. Then I'll have to re-set the file mode to 755 manually after editing and before committing.

Thanks for the replies.