Cannot do git checkout -- . or git reset --hard when affected files' mode changed from 100755 to 100644

[chenzx]

• 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.19.1.windows.1
cpu: x86_64
built from commit: 11a3092e18f2201acd53e45aaa006f1601b6c02a
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 [▒汾 6.1.7601] **

• 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: Notepad++
Custom Editor Path:
Path Option: BashOnly
Plink Path: C:\Program Files\TortoiseGit\bin\TortoiseGitPlink.exe
SSH Option: Plink
CURL Option: OpenSSL
CRLF Option: CRLFCommitAsIs
Bash Terminal Option: MinTTY
Performance Tweaks FSCache: Enabled
Use Credential Manager: Enabled
Enable Symlinks: Disabled
Enable Builtin Rebase: Disabled
Enable Builtin Stash: Disabled
 **

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

** insert your response here **

Details

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

** Bash **

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

** git checkout -- . or git reset --hard **

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

** All the files in git status output list should be reset **

• What actually happened instead?

** cannot reset these files' status **

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

** no **

[chenzx]

$ git diff 1.txt
diff --git a/1.txt b/1.txt
old mode 100755
new mode 100644

i guess this is the problem: Git for windows cannot do reset, when the git modification is only file mode from 755 to 644 (on Linux it's ok)

[dscho]

I just did this in a clone of Git for Windows' own git.git fork:

$ git add --chmod=+x README.md

$ git commit -m "Test: mark README as executable"
[master 04d4b5e43b24] Test: mark README as executable
 1 file changed, 0 insertions(+), 0 deletions(-)
 mode change 100644 => 100755 README.md

$ git reset --hard HEAD^
HEAD is now at 2c704875d008 Merge pull request #1915 from dscho/open-in-gdb

$ git reset --hard HEAD@{1}
HEAD is now at 04d4b5e43b24 Test: mark README as executable

$ git show
commit 04d4b5e43b2411644cfdd3a99af7631c196a8dbb (HEAD -> master)
Author: Johannes Schindelin <johannes.schindelin@gmx.de>
Date:   Mon Nov 12 16:00:29 2018 +0100

    Test: mark README as executable

diff --git a/README.md b/README.md
old mode 100644
new mode 100755

As you can see, your "Minimal, Complete, Verifiable Example" is not verifiable here.

[chenzx]

Can i ask:

$ git add --chmod=+x README.md

Where does this command execute? Linux or Windows?

Our git env is hybrid: the remote git repo is on Linux, and i use 2 client clones: one is on Windows, for code edit, and one is on another linux, for cross-compiling...

The file mode change is done on Linux env.

[chenzx]

The file mode change is not done by me, but by another team guy, who use ubuntu os client, and maybe trigger these changes by chown -R ... commands, which i'm not very clear.

[dscho]

Can i ask:

$ git add --chmod=+x README.md

Where does this command execute? Linux or Windows?

It does not matter. This is the way to tell Git that this file is executable when you do not know whether chmod works.

And it does not matter how your colleague makes their changes as long as you can produce an MCVE. So far, there is no way for me to verify your claim. My only chance is to go on a wild goose chase (which is an incredible time waster on my side) trying to recreate what may have happened on your side, and even if I would manage to see the same symptoms (I did not manage that, as I demonstrated earlier), then I still would not know that it is actually the same underlying problem.

So you see, there is really no alternative to you producing a public repository with which you can reproduce the symptom reliably on your side, them make that available to others so that they can verify, and then fix.

[chenzx]

someone has met with the same problem and gives a fix:

git config core.filemode false

That's it, problem fixed.

[chenzx]

https://stackoverflow.com/questions/1257592/how-do-i-remove-files-saying-old-mode-100755-new-mode-100644-from-unstaged-cha

[tbertels]

someone has met with the same problem and gives a fix:

git config core.filemode false

That's it, problem fixed.

Could that setting be set by default on Git for Windows?

That stackoverflow question above was viewed 174k times, so it's fair to say that it's a common problem on Windows.

[PhilipOakley]

core.filemode is an assertion about your file system / operating system that is usually tested by Git when the repository is created on your machine (where your file system resides).

• "Tells Git if the executable bit of files in the working tree is to be honored."
• git-clone(1) or git-init(1) probe the filesystem to see if it handles the executable bit correctly and this variable is automatically set as necessary.
• Some filesystems lose the executable bit when a file that is marked as executable is checked out, or checks out a non-executable file with executable bit on.

Changing the filemode based on a random internet command is, like all such suggestions, fraught with possible failures and misunderstandings.

In mixed environments, you do need a bit more social cohesion to ensure that everyone works cooperatively in our multi-cultural diverse community.

Do have a read through the git help config page for the filemode discussions.

[tbertels]

The problem is that neither git clone nor git init are run when a user downloads an archive of a tree and extracts it, which is is the fastest way to download a tree.

So adding this probing to git reset would probably be a good idea.

[PhilipOakley]

run when a user downloads an archive of a tree and extracts it,

Hmm, maybe it's not the Git way. Which (other) XY problems does this solve?

• Slow network
• Not yet using the new blob/tree filter options
• needing to plant the tree onto an otherwise non-mergable branch (similar to a checkout while dirty with conflicts)

adding this probing .. would probably be a good idea.

It probably ought to be a separate command (see XY above), or command option, e.g.
git config --probe=core.filemode
or some such. That way the core code can be pulled out as it's own function then exposed for other uses (especially for networked FS with multiple OS versions behind them)

[dscho]

The problem is that neither `git clone` nor `git init` are run when a user downloads an archive of a tree and extracts it, which is is the fastest way to download a tree.

That is the problem all right. Git is not designed to work in such a way, that's why the `git init` command exists and does more than just copying around a couple of files.

So adding this probing to `git reset` would probably be a good idea.

No, it would not be a good idea: who says that the state would be consistent if `git reset` randomly changes fundamental values that are expected not to change over the life-time of a worktree?

[PhilipOakley]

So adding this probing to git reset would probably be a good idea.
No, it would not be a good idea: who says that the state would be consistent if git reset randomly changes fundamental values that are expected not to change over the life-time of a worktree?

@tbertels The question (given dscho's comment) becomes "why do you have a tree with one set of embedded modes, supposedly for the same repo, such that when it's extracted to the worktree, you have the mode conflict?"

It implies that the team isn't working together for mutual benefit, and may have wider issues, e.g. not being able to fetch and having to use archives, or not mutually understanding how/when the executable bit is set and stored within git (as distinct from the FS), no policy on how/when the executable bit should be set, etc.

[tbertels]

In this case, it was for LibreOffice (https://www.libreoffice.org/about-us/source-code/), the full list of tarballs is on https://dev-www.libreoffice.org/bundles/
The tarballs have most likely been made on Linux, and extracting them on Windows creates the issue.

[dscho]

@tbertels are you saying that they tarred up Git worktrees, including Git configs?

[tbertels]

Yes, they have.

[dscho]

Yes, they have.

Well, that is the bug, then.

What they should probably consider instead is to create a Git bundle via git bundle create ..., and adjust their instructions. It will also make everything a lot faster and smaller because the worktree files are skipped (and as a consequence, git status will not be dealing with totally bogus timestamps).

In other words, the root cause of this problem really is incorrect Git usage, as Git was not designed to work in the way LibreOffice apparently expects it to work.