Git: As of 2.27.0, all symlinks have modifications after stash pop

Created on 2 Jun 2020  Â·  14Comments  Â·  Source: git-for-windows/git

Setup

  • Which version of Git for Windows are you using? Is it 32-bit or 64-bit?
git version 2.27.0.windows.1
cpu: x86_64
built from commit: 907ab1011dce9112700498e034b974ba60f8b407
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?
Microsoft Windows [Version 10.0.18363.836]
(c) 2019 Microsoft Corporation. All rights reserved.
  • What options did you set as part of the installation? Or did you choose the
    defaults?
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

Details

  • 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

bug git

All 14 comments

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 symlinks
  • git status on the command shows the modified status
  • Visual Studio's "Changes" tab in the Team Explorer shows the modified status

What'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 status
  • Visual Studio's "Changes" tab in the Team Explorer shows no modified status
  • git gui does show the modified status for the symlinks, but when selecting the file in "Unstaged Changes", a dialog pops up:
    image

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.

Bisected to 2f55cc4 (obviously), and it is _not fixed_ by f18046e.

Right.

I _think_ I have a correct and complete fix in https://github.com/git-for-windows/git/pull/2673. @orgads would you mind testing it?

@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

Was this page helpful?
0 / 5 - 0 ratings

Related issues

kc22033 picture kc22033  Â·  4Comments

jesterKing picture jesterKing  Â·  3Comments

Snaptags picture Snaptags  Â·  4Comments

daxelrod picture daxelrod  Â·  4Comments

drewnoakes picture drewnoakes  Â·  5Comments