`git restore` after `git cherry-pick -n` can leave GVFS in a bad state

[tyrielv]

1. Use git cherry-pick -n to cherry-pick some changes to current branch, leaving them uncommitted
2. Use git restore --staged to unstage the changes

Expected:
All the changes from the cherry-pick move from staged to unstaged in git status.

Actual:
Sometimes some changes disappear from git status.
The files still have the changed contents, but git no longer recognizes the files as being changed.

It's unclear so far whether cherry-pick -n is required or if manual changes with git add will also repro.

git checkout to another branch appears to properly reset the file contents. (I've heard others complain about situations where it did not, though I don't know if they were caused by this and I haven't repro'd that.)

[tyrielv]

I think it has to do with handling of skip-worktree flag in the index, which was added in v4 of index format to support sparse-checkout.

In a GVFS repo most files are skip-worktree=True by default.

If you git add a file to stage it, then it changes to skip-worktree=False and git restore --staged will work as expected.

If you stage a file via another way, such as git cherry-pick -n, it does not change skip-worktree, and git restore --staged will exit early, which results in updating the index to unstage, leaving the file untouched (ie in modified state), but with skip-worktree=true so further git commands don't recognize that the file is in modified state. edit: git restore --staged will actually update skip-worktree to false, but doesn't notify GVFS that it changed it.

I verified that it works as I described with another way to stage a file, git reset --soft HEAD~1 to checkout the prior commit but leave the working directory files in their current state for the files changed in current commit and stage them in the index.

It looks like this is related to several prior issues around skip-worktree:
microsoft/git#683
microsoft/git#490
microsoft/git#646

A fix might be for all ways to stage a file to set skip-worktree=false in a GVFS repo, or for whichever point is modifying the file on disk to do so. (Non-GVFS sparse-checkout repos (eg using Scalar) I'd expect to not modify the file on disk if it's outside the sparse-checkout, so inserting the change at point of modifying the file is probably simpler.)

[tyrielv]

PostIndexChanged sends two flags: UpdatedWorkingDirectory and UpdatedSkipWorktreeBits.

git restore --staged in this scenario sets neither of these flags when it triggers PostIndexChanged, but is actually updating SkipWorktreeBits. GVFS gets into a bad state because it uses UpdatedSkipWorktreeBits as a signal to invalidate its cached modified file list, and the list is incorrect after this.

[tyrielv]

Another reported scenario that may be related - "git restore --source"