Refresh git state after branch switch so SSH projects update the branch name

[kkoshin]

Summary

In a remote (SSH) project, clicking a branch in the branch picker switches the branch successfully (verified on the host with git branch --show-current / cat .git/HEAD), but the branch name shown in Zed's UI never updates. Local projects are unaffected.

This is the same family of bugs as #55133 / #13176. Two recent PRs (#59876, #61541) hardened the worktree file watcher so .git metadata changes reliably trigger a git-state reload. After those landed, however, a UI-initiated branch switch in an SSH project still leaves the branch indicator / branch picker stale for me — because change_branch itself still relies on the remote host's file watcher catching the .git/HEAD write, and that round-trip is not reliable on the SSH host in question. This change makes the UI-initiated switch not depend on the watcher, mirroring how reset and fetch already work.

Root cause

Repository::change_branch ran backend.change_branch() (local) or sent a GitChangeBranch RPC (remote) and returned, relying entirely on the worktree file watcher noticing the .git/HEAD change to re-scan and propagate the new branch. On the SSH host that round-trip does not reliably fire, so the server never sends a downstream UpdateRepository with the new branch_summary, the client's apply_remote_update never emits HeadChanged, and the UI stays stale until something else touches .git.

This is inconsistent with the sibling mutating operations, both of which explicitly refresh git state after the mutation rather than trusting the watcher:

• Repository::reset calls schedule_scan(updates_tx, cx) after the job.
• Repository::fetch calls refresh_branch_list(...) after a successful fetch.

change_branch did neither.

Fix

Mirror reset: make Repository::change_branch call schedule_scan(updates_tx, cx) after the change job.

• Local repo: schedule_scan(None) → compute_snapshot reads the new branch, emits HeadChanged locally.
• SSH server: schedule_scan(Some(tx)) → compute_snapshot reads the new branch, sends DownstreamUpdate::UpdateRepository over the downstream channel → the client's apply_remote_update sees the new branch_summary and emits HeadChanged.
• SSH client: its own git store is GitStoreState::Remote, so no local scan runs; the server does it.

schedule_scan is keyed by GitJobKey::ReloadGitState, so any scan additionally triggered by the watcher is deduped — this change is purely additive and never causes a double scan.

Because schedule_scan needs cx: &mut Context<Self> (matching reset's signature), change_branch now takes cx. Updated the branch picker, the server-side handle_change_branch, the agent worktree archive caller, and the collab/remote_server integration tests. Added assertions in test_remote_git_branches that the downstream client repository observes the new branch after a remote switch.

Because compute_snapshot recomputes the full snapshot — branch, HEAD commit, file statuses, and diff stats — the git panel's file list and per-file diff stats refresh together with the branch name, all via the same reliable path.

Caveats

• I could not reproduce the watcher-unreliability deterministically in the FakeFs-based integration tests (FakeFs delivers watcher events perfectly), so the added assertions pass via the watcher path even without this change and do not, on their own, prove the fix. The evidence that this change matters is a real-world SSH reproduction: on a build that already includes Refresh git state on bare .git events #59876 / worktree: Reload git state when a watcher rescan covers a repository #61541, clicking a branch switch in an SSH project still leaves the branch indicator stale; with this change it updates immediately.
• I did not pinpoint exactly why the SSH host's watcher misses the .git/HEAD write after Refresh git state on bare .git events #59876 / worktree: Reload git state when a watcher rescan covers a repository #61541. The motivation for this change is consistency with reset / fetch: an in-app mutating git operation should refresh deterministically rather than depend on the remote watcher. If maintainers would rather chase the watcher root cause, I'm happy to help investigate; this PR is intended as a complementary, low-risk fix that makes the UI action not depend on the watcher at all.

Related

• Closes Remote SSH project: branch indicator and branch picker stay stale after branch switch/create until restart #55133 (stale branch indicator / picker after switch in SSH projects), which was closed as a duplicate of Git information can get out of sync #13176.
• Complements Refresh git state on bare .git events #59876 and worktree: Reload git state when a watcher rescan covers a repository #61541, which fixed the watcher path for stale git state but leave the UI-initiated switch still watcher-dependent.

Release Notes:

• Fixed the branch name in the UI not updating after switching branches in a remote (SSH) project, even though the switch succeeded on the host.

[kkoshin]

@cla-bot check

[cla-bot]

The cla-bot has been summoned, and re-checked this pull request!

[kkoshin]

@MrSubidubi
The 5 workflow runs for this PR are sitting in action_required, waiting for a maintainer to approve them (first-time contributor). Could one of you approve the runs so CI can execute? Happy to fix any failures that come up.

Thanks!

[cole-miller]

Thanks for opening a PR. I'd definitely love to understand why our watcher code (or UpdateRepository) is not doing its job here; could you try reproducing this while having some additional logging enabled in your settings.json, so we can see why the git state is not being refreshed in your case?

// in settings.json

"log": {
  "worktree": "trace"
}