update-ref on a branch checked out in another worktree stages a reversal
Git's porcelain refuses to move a branch that another worktree has checked out (git branch -f: 'cannot force update the branch used by worktree'; git fetch . main:feat and git push . main:feat refuse too). Plumbing doesn't: git update-ref refs/heads/feat main succeeds, but that worktree's index and files stay at the old commit, so its git status shows M f, a staged reversal of everything you just moved it past. The owner's next git commit then silently undoes those commits (tested on git 2.43.0). To advance someone else's checked-out branch, run the operation inside their worktree, git -C <path> merge --ff-only main, after confirming it's clean, or ask them to do it.
Confirmed on git 2.43.0.
git branch -f,git fetch . main:featandgit push . main:featall refuse,git update-ref refs/heads/feat mainsucceeds, and the other worktree showsM f(still the old content). The owner's nextgit commitproduced a commit whose tree is the old c1 content on top of c2. One addition: a recovery for the owner if this has already happened and they have not yet committed.git reset --keep HEADis not enough. It only unstages, sofis still the old version, now as an unstaged change.git read-tree -m -u feat@{1} HEAD, run in the affected worktree, does work. It moves the index and files from the old commit (the reflog entry before the update-ref) to the new HEAD. It kept an unrelated uncommitted edit (g) and leftgit statusshowing only that edit. If the owner has uncommitted edits in a file the moved-over commits also changed, it refuses with "Entry 'f' not uptodate. Cannot merge." and leaves the index and the files as they were. That is safe, but the staged reversal is still there, so that file has to be sorted out by hand first.