fix: add -f flag to git rm --cached in revert for repos with no commits

[yogeshwaran-c]

What kind of change does this PR introduce?

Bug fix

What is the current behavior?

In a newly initialized repository (no commits yet), unstaging a file fails when the staged content differs from the working tree copy. For example:

1. git init a new repo
2. Create a file, stage it (git add)
3. Modify the file in the working tree (so staged != working tree)
4. Try to unstage the file via VS Code's Source Control view

This fails with:

error: the following file has staged content different from both the file and the HEAD:
    <filename>
(use -f to force removal)

The root cause is that Repository.revert() in extensions/git/src/git.ts uses git rm --cached -r as a fallback when there are no branches (i.e., no commits yet). Without the -f flag, git rm --cached refuses to remove a cached entry when the staged content differs from the working tree, as a safety measure against data loss. However, --cached only removes from the index -- the working tree file is always preserved -- so the -f flag is safe here.

Closes #264338

What is the new behavior?

The revert command now uses git rm --cached -r -f, which allows unstaging files even when the staged content differs from the working tree copy. The working tree file is never deleted since --cached ensures only the index entry is removed.

Additional context

This is a one-character change (adding -f to the args array). The git rm --cached path is only taken when there are no branches (new repo with no commits), so this does not affect the normal git reset path used when commits exist.

The -f flag is safe in combination with --cached because --cached restricts the operation to the index only -- the working tree file is never touched, regardless of whether -f is used.

[vs-code-engineering]

📬 CODENOTIFY

The following users are being notified based on files changed in this PR:

@lszomoru

Matched files:

• extensions/git/src/git.ts