Summary
The github/awesome-copilot marketplace appears to rewrite main history, and that is not compatible with how VS Code currently updates chat plugin marketplaces.
VS Code’s built-in chat/plugin updater is doing a fast-forward-only pull for the local marketplace clone. When main is force-pushed upstream, the local clone diverges and every later update attempt fails.
What I’m seeing
VS Code logs this repeatedly whenever there is a new remote commit on github/awesome-copilot:
[PluginInstallService] Failed to pull marketplace 'github/awesome-copilot': Command failed: git pull --ff-only
hint: Diverging branches can't be fast-forwarded, you need to either:
hint:
hint: git merge --no-ff
hint:
hint: or:
hint:
hint: git rebase
fatal: Not possible to fast-forward, aborting.
Why this seems to happen
Locally, the marketplace clone ends up in a state like this:
- local
main is on an older commit
origin/main has been force-updated to a different history
- the working tree is clean
git pull --ff-only fails because the branch relationship is no longer fast-forwardable
I also observed forced-update entries in the remote-tracking reflog for origin/main, which suggests this is not just a normal linear branch update.
Repro
- Let VS Code clone/update
github/awesome-copilot as a chat plugin marketplace.
- Wait for an upstream change where
main is rewritten / force-pushed.
- Let VS Code attempt its normal marketplace update.
- The update fails because it runs
git pull --ff-only against a now-diverged local clone.
Expected behavior
One of these should be true:
main remains linear / fast-forwardable so clients using git pull --ff-only can update cleanly, or
- there is a documented immutable/stable ref or release branch intended for marketplace consumers
Actual behavior
The upstream history changes in a way that causes marketplace clients using fast-forward-only pulls to fail permanently until the local clone is manually reset or deleted.
Impact
This causes persistent update failures in VS Code’s built-in chat/plugin marketplace flow for users tracking github/awesome-copilot.
Request
Would you consider one of these options?
- Avoid force-pushing the branch that marketplace consumers are expected to track.
- Provide a stable branch specifically for marketplace consumption.
- Document that the repo intentionally rewrites history, so downstream clients know they must hard-reset rather than pull.
I realize the updater behavior is on the VS Code/Copilot side, but the current branch publication strategy appears to be incompatible with that client behavior, so I wanted to report it here as well.
Summary
The
github/awesome-copilotmarketplace appears to rewritemainhistory, and that is not compatible with how VS Code currently updates chat plugin marketplaces.VS Code’s built-in chat/plugin updater is doing a fast-forward-only pull for the local marketplace clone. When
mainis force-pushed upstream, the local clone diverges and every later update attempt fails.What I’m seeing
VS Code logs this repeatedly whenever there is a new remote commit on
github/awesome-copilot:Why this seems to happen
Locally, the marketplace clone ends up in a state like this:
mainis on an older commitorigin/mainhas been force-updated to a different historygit pull --ff-onlyfails because the branch relationship is no longer fast-forwardableI also observed
forced-updateentries in the remote-tracking reflog fororigin/main, which suggests this is not just a normal linear branch update.Repro
github/awesome-copilotas a chat plugin marketplace.mainis rewritten / force-pushed.git pull --ff-onlyagainst a now-diverged local clone.Expected behavior
One of these should be true:
mainremains linear / fast-forwardable so clients usinggit pull --ff-onlycan update cleanly, orActual behavior
The upstream history changes in a way that causes marketplace clients using fast-forward-only pulls to fail permanently until the local clone is manually reset or deleted.
Impact
This causes persistent update failures in VS Code’s built-in chat/plugin marketplace flow for users tracking
github/awesome-copilot.Request
Would you consider one of these options?
I realize the updater behavior is on the VS Code/Copilot side, but the current branch publication strategy appears to be incompatible with that client behavior, so I wanted to report it here as well.