• 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.45.0.vfs.0.0
cpu: x86_64
built from commit: b68812e6facef46153bdeb3d79c1b8f353b8e94d
sizeof-long: 4
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon

Are you using Scalar or VFS for Git?

VFS for Git.

$ 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.26203.5000]

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

The repo is the Windows monorepo

Details

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

PowerShell via Terminal Windows app

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

# on a fresh clone of the Windows monorepo
git reset --mixed head~1

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

I expected the files modified by the most recent commit to be moved to the "unstaged" status.

• What actually happened instead?

Running git status reported that the working tree was clean. Note that if I had instead run git reset --soft head~1, the files would have correctly been put into the staged state. Subsequently running git reset --mixed head would trigger the repro, though.

This seems very similar to #490. @derrickstolee FYI.

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