Try this: # a repo with one file git init repo cd repo echo base >file git add file git commit -m base # now stash a modification echo modified >file git stash # then make the file stat dirty. This will change inode; on systems # without inodes, probably "sleep 1; touch file" would work. cp file other mv other file # now try to apply the stash git stash apply The final command gives me: error: Your local changes to the following files would be overwritten by merge: file Please commit your changes or stash them before you merge. Aborting This started with 8a0fc8d19d (stash: convert apply to builtin, 2019-02-25), which is in v2.22.0. Interestingly, do_stash_apply() does in fact call refresh_cache(). But it looks like we don't ever write it out to disk. So when we later call merge_recursive(), it presumably uses the on-disk index, not what we have in memory. It's not clear to me where the fix should go, though. Should "stash apply" be writing out the refreshed index before proceeding? Or should merge_recursive() be more careful about refreshing the index after it locks it? The former is what happened with stash as a shell script, but the latter would save us an otherwise pointless write. I'm also not sure if other parts of stash might have a similar bug due to the conversion to C. I think it's an easy mistake when converting "git update-index --refresh" into "refresh_cache()" and then some other part of the code takes the index lock (and thus looks at that index, not what we have in memory). -Peff
