Git reset --mixed HEAD~1 still losing track of some files

[rossnichols]

• I was not able to find an open
  or closed issue matching
  what I'm seeing, including in the git-for-windows/git tracker.

Setup

• Which version of microsoft/git are you using? Is it 32-bit or 64-bit?

$ git --version --build-options

git version 2.46.0.vfs.0.0
cpu: x86_64
built from commit: 081a80eda51c258b0a2a3b9fc786143d03edc926
sizeof-long: 4
sizeof-size_t: 8
shell-path: D:/git-sdk-64-build-installers/usr/bin/sh
feature: fsmonitor--daemon
libcurl: 8.9.0
OpenSSL: OpenSSL 3.2.2 4 Jun 2024
zlib: 1.3.1

Are you using Scalar or VFS for Git?

GVFS

If VFS for Git, then what version?

$ gvfs version

GVFS 1.0.24074.1

• Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?

$ cmd.exe /c ver

Microsoft Windows [Version 10.0.26273.5000]

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

I'm reproing this issue in the Windows monorepo.

Details

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

PowerShell 7.4.5

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

1. Clone the Windows os.2020 repo
2. `git reset --hard 1e867fe0d335c` (or some other commit that has a decent number of changed files)
3. Launch razzle to trigger the hydration of some files
4. `git reset --soft head~1`
5. `git status` (shows 44 modified, 14 new, 1 deleted)
6. `git reset --mixed head`
7. `git status` (shows 35 modified, 1 deleted, 3 untracked files/directories that cover the 14 new files)

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

I expected to continue to see 44 modified files, just unstaged instead of staged.

• What actually happened instead?

Git lost track of some unstaged files.

• If the problem was occurring with a specific repository, can you specify
  the repository?

  • Public repo: insert URL here
  • Windows monorepo
  • Office monorepo
  • Other Microsoft-internal repo: insert name here
  • Other internal repo.

This issue has been previously reported via #490 and #646. The fix does not yet seem complete, though - every time I cherry-pick a commit and run git reset --mixed head~1 to go through it and make updates, I risk losing files.

Note that first running the soft reset is NOT a prerequisite to repro - I only performed it to demonstrate the discrepancy. However, having some amount of hydrated files IS a prerequisite (hence launching razzle to simply trigger it going off and hydrating files on the new repo).

The bug does NOT repro in a given directory if I explicitly dehydrate the directory that contains a "lost" file. For example, if file "foo/bar/baz.cpp" was lost, and I reset --hard back to the original commit, then running gvfs dehydrate i:\os1\src --confirm --folders "foo/bar" before trying git reset --mixed head~1 will fix that file. Similarly, running gvfs dehydrate --confirm to dehydrate everything also makes the repro go away completely.

It's also worth calling out that if I browse to a "lost" file, the expected changes are present, and if I save the file (e.g. after making a modification and undoing it), git now tracks the expected changes. Simply opening the file is insufficient to fix it (git will continue to overlook it), I have to resave it. Once it's fixed, it remains fixed if I repeat the repro steps. Similarly, if I open and save a file before performing the mixed reset, it will not be lost.

So overall, it seems to impact files that have not been edited locally (even if they've been viewed), but whose directories have been hydrated. At least, that's what my experimentation seems to show.

@derrickstolee FYI.

[dscho]

@rossnichols does this also happen if you use the (correct) spelling HEAD~1 (instead of the lower-case head~1, which is known to cause problems)?

[rossnichols]

@dscho I seem to have lost the repro right now, even on new clones :(. I haven't figured out how to transition from working to broken, only broken to working (the dehydrate commands) - doing gvfs prefetch --hydrate ... doesn't seem to go back to broken).

All I can add, though, is that using VSCode's GUI to transition between staged and unstaged was also susceptible to this, though I don't know the commands it runs under the hood.

I'll see if I can get the repro again.