git version 2.27.0.windows.1
cpu: x86_64
built from commit: 907ab1011dce9112700498e034b974ba60f8b407
sizeof-long: 4
sizeof-size_t: 8
Microsoft Windows [Version 10.0.18363.836]
(c) 2019 Microsoft Corporation. All rights reserved.
Editor Option: VIM
Custom Editor Path:
Path Option: Cmd
SSH Option: OpenSSH
Tortoise Option: false
CURL Option: OpenSSL
CRLF Option: CRLFAlways
Bash Terminal Option: MinTTY
Git Pull Behavior Option: Merge
Performance Tweaks FSCache: Enabled
Use Credential Manager: Enabled
Enable Symlinks: Enabled
Enable Pseudo Console Support: Disabled
Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other
Windows Terminal (Preview) running PowerShell. I'm explicitly not running git from WSL (ever)
What commands did you run to trigger this issue?
> git stash
> git stash pop
What did you expect to occur after running these commands?
The number of modified files before and after the commands should be the same.
What actually happened instead?
I have read the release notes of 2.27.0 regarding the symlink behavior. I had the modified symlink files and ran git add -u on them. However, after stash and pop, all symlinks are back to the modified state even though they were not before.
Related: #2637
CC @billziss-gh
Steps to reproduce in an empty folder within a PowerShell prompt:
> git init
Initialized empty Git repository in …/.git/
> echo "a" > a.txt
> cmd
Microsoft Windows [Version 10.0.18363.836]
(c) 2019 Microsoft Corporation. All rights reserved.
>mklink b.txt a.txt
symbolic link created for b.txt <<===>> a.txt
Volume in drive C is OS
Volume Serial Number is …
Directory of …
02.06.2020 14:27 <DIR> .
02.06.2020 14:27 <DIR> ..
02.06.2020 14:27 <SYMLINK> b.txt [a.txt]
2 Dir(s) 171.432.267.776 bytes free
>exit
> dir
Directory: …
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 02.06.2020 14:27 8 a.txt
-a---l 02.06.2020 14:27 0 b.txt
> git add .
> git commit -m 'Commit'
[master (root-commit) 7761e65] Commit
2 files changed, 1 insertion(+)
create mode 100644 a.txt
create mode 120000 b.txt
> echo "a" >> a.txt
> git status
On branch master
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: a.txt
no changes added to commit (use "git add" and/or "git commit -a")
> git stash
Saved working directory and index state WIP on master: 7761e65 Commit
> git stash pop
On branch master
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: a.txt
modified: b.txt
no changes added to commit (use "git add" and/or "git commit -a")
Dropped refs/stash@{0} (a10b62bae9d511cb63c13a103f28707a850da436)
I'm confused:
git gui does not show the modified status for the symlinksgit status on the command shows the modified statusWhat's different in Git Gui?
What's different in Git Gui?
I guess that Git GUI parses the output of git diff, and that command does not report any changes.
Now things get weird. I'm in a second repository that largely resembles same symlink structure, but I never ran git add -u (if that matters). Here, the situation regarding the modified state is exactly the opposite to the first repository:
git status on the command line shows no modified statusgit gui does show the modified status for the symlinks, but when selecting the file in "Unstaged Changes", a dialog pops up:
git diff on the command line does not show anything for the symlinks.
I'm on my phone right now, so I cannot test: could you try again after running git config core.fscache false?
I have the same situation here. Every time I run git reset --hard (or merge, or other operations), all the symbolic links appear as modified, and only git add . helps.
I just checked setting core.fscache to false, and it solved the issue.
I see the same issue too - and it also happens when freshly cloning a repository containing symbolic links. My team is reverting to a prior version to avoid the issue for now.
Bisected to 2f55cc471e41028d08bd6ac33c25c1b587bb2660 (obviously), and it is not fixed by f18046e6ae891fbb39087ef5386a46417e7b9b42.
@Tragetaschen @mrsvk could I ask you to test the installer and/or portable Git generated from this PR? They can be found here: https://dev.azure.com/git-for-windows/git/_build/results?buildId=57380&view=artifacts&type=publishedArtifacts
Will do first thing tomorrow
@dscho I did the same simple test case I had done previously (git clone -> git status). The new build results in the expected clean status, instead of flagging every symlink. This looks to have resolved the issue for me - thank you.
Tested. It works for me. Thank you!
I tested it in both my repositories and they behave normally now