microsoft / git

A fork of Git containing Microsoft-specific patches.
http://git-scm.com/
Other
782 stars 92 forks source link

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

Open rossnichols opened 2 months ago

rossnichols commented 2 months ago

Setup

$ 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
$ cmd.exe /c ver

Microsoft Windows [Version 10.0.26273.5000]

I'm reproing this issue in the Windows monorepo.

Details

PowerShell 7.4.5

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)

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

Git lost track of some unstaged files.

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 commented 2 months ago

@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 commented 2 months ago

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