git stash leaving modified files?

Question

I'm getting some odd behavior when trying to stash changes. I'm not a git expert so I'm hoping someone can shed some light on this:

1. On an up-to-date branch, I modify a tracked file. git status shows it as modified
2. git stash (responds with "Saved working directory and index state WIP on...)
3. git status still shows the file as modified, but git diff (and git gui) show no changes.
4. git stash list shows the stash was created
5. git stash pop responds with "error: Your local changes to the following files would be overwritten by the merge:"

The behavior at 3 makes no sense to me. It started happening fairly recently. I've been using stash/stash pop for several months with no problems.

I wondered whether there was an issue with my local working copy so I re-cloned but get the same behavior.

Is my GIT installation broken, or am I missing something?

Additional info:

• Tried this on another PC and it behaves as expected, so it's something to do with this installation.

• Tried creating a new local repo, add & commit 1 file, modify, stash. Same behavior

• Tried with files with CR LF and LF line endings. Same behavior

git config -l:

core.symlinks=true
core.autocrlf=true
core.fscache=true
color.diff=auto
color.status=auto
color.branch=auto
color.interactive=true
help.format=html
diff.astextplain.textconv=astextplain
rebase.autosquash=true
http.sslcainfo=C:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crt
http.sslbackend=openssl
diff.astextplain.textconv=astextplain
filter.lfs.clean=git-lfs clean -- %f
filter.lfs.smudge=git-lfs smudge -- %f
filter.lfs.process=git-lfs filter-process
filter.lfs.required=true
credential.helper=manager
core.editor='C:\Program Files (x86)\Notepad++\notepad++.exe' -multiInst -    notabbar -nosession -noPlugin
core.excludesfile=C:\GIT\gitignore\VisualStudio.gitignore
core.editor=notepad
core.fscache=true
core.preloadindex=true
gui.fontdiff=-family Consolas -size 10 -weight normal -slant roman -    underline 0 -overstrike 0
gui.recentrepo=C:/GIT/polarisv4
filter.lfs.clean=git-lfs clean -- %f
filter.lfs.smudge=git-lfs smudge -- %f
filter.lfs.process=git-lfs filter-process
filter.lfs.required=true
user.name=xxxxx
user.email=xxxxxx
difftool.sourcetree.cmd='C:/Program     Files/TortoiseGit/bin/TortoiseGitMerge.exe' "$LOCAL" "$REMOTE"
mergetool.sourcetree.cmd='C:/Program     Files/TortoiseGit/bin/TortoiseGitMerge.exe'  -base:"$BASE" -mine:"$LOCAL" -    theirs:"$REMOTE" -merged:"$MERGED"
mergetool.sourcetree.trustexitcode=true
alias.co=checkout
alias.br=branch
alias.st=status
winupdater.recentlyseenversion=2.15.1.windows.2
credential.helper=manager
core.repositoryformatversion=0
core.filemode=false
core.bare=false
core.logallrefupdates=true
core.ignorecase=true

Answer 1

As DaveW said the problem comes from the core.fscache=true setting. This is a Windows only setting that enable a file system cache in order to mitigate slowness of some Windows file system operations. Here is the description extracted from the commit message Win32: add a cache below mingw's lstat and dirent implementations:

Checking the work tree status is quite slow on Windows, due to slow lstat emulation (git calls lstat once for each file in the index). Windows operating system APIs seem to be much better at scanning the status of entire directories than checking single files.

Add an lstat implementation that uses a cache for lstat data. Cache misses read the entire parent directory and add it to the cache. Subsequent lstat calls for the same directory are served directly from the cache.

Also implement opendir / readdir / closedir so that they create and use directory listings in the cache.

The cache doesn't track file system changes and doesn't plug into any modifying file APIs, so it has to be explicitly enabled for git functions that don't modify the working copy.

The last sentence of this commit message gives an indication of the cause of the OP problem.