7 Commits

Include renames

Author	SHA1	Message	Date
Neil	d3501f7ad6	fix(worktrees): stop a failed worktree scan from being recorded as an authoritative empty listing (#18456) ... * fix(worktrees): stop a failed worktree scan from pruning as an authoritative empty listing A `git worktree list` that could not run at all — a WSL distro that stopped resolving, a hung mount, a git binary that errored — was softened to `[]` by the lenient listing path, so the detected scan published it as `authoritative: true, worktrees: []`. That disables the #1158 retention guard, drops every persisted tab for the repo, and the pruned session is written back to disk on the next launch. The loss is permanent, not a transient glitch. Route the detected scan through a strict listing that still reports the two genuinely empty states (repo path gone, not a Git repo) as `[]`. Everything else rejects, so the existing catch answers `authoritative: false` and the destructive halves (`rememberLocalWorktreeRoots`, `pruneLineageForMissingRepoWorktrees`) never see a failed scan. Also make the failure readable: wsl.exe reports its own launch failures as exit 0xFFFFFFFF with an EMPTY stderr and the `Wsl/Service/WSL_E_*` line on stdout as UTF-16LE, which is why the field bundle carried a git error with no text. Set WSL_UTF8 for WSL-routed git (matching the wsl runner, #9010) and attach that stdout diagnostic to the error so `git.exec` spans name the cause. * fix(worktrees): surface a failed worktree scan's cause on the repo header with a retry A failed scan now travels with its reason (optional unavailableReason on DetectedWorktreeListResult), the repo header shows it with click-to-retry, and the WSL deleted-guest-directory shape measured on a real Windows host is pinned as retained-not-pruned.	2026-09-04 15:23:09 -07:00
Neil	a7db6c336b	perf(git): skip the sparse probe for worktree listings that never read it (#18050) ... Three main-process call sites list a repo's worktrees to read `worktree.path` and nothing else, but went through the annotated listing, so each one paid a sparse-checkout probe per worktree and cached the result nobody consumed: - `registered-worktree-roots-cache.ts` rebuilds the filesystem-auth authorized roots. `invalidateAuthorizedRootsCache()` fires on every worktree create and remove, plus repo add/clone/settings changes, so this reruns constantly. - `filesystem-source-control-ai-targets.ts` checks whether a local repo owns a worktree path. - `hosted-review.ts` verifies a worktree belongs to the repo before granting access. The probe is an `fs.stat` of the per-worktree `info/sparse-checkout` plus, when that file is non-empty, a git config read. On a WSL-hosted repo both cross 9p. #17859 cached it and #17932 keyed that cache on the distro, which fixed a wrong answer but also meant the distro-less callers above populate a second entry per worktree — probed cold, revalidated on their own five-minute loop, and read by nobody. Worktree create/remove clears the sparse cache and dirties the roots cache together, so both variants go cold at once and the discarded half is re-probed in full on the next auth check. `listRepoWorktreeGraph` routes those callers to `listWorktreeGraph`, which already existed as the annotation-free listing (#17655). Doing only that would have cost a second `git worktree list`. The scan cache keys in-flight scans on a `kind`, and graph and lenient were separate kinds, so a roots rebuild overlapping a sidebar refresh would spawn its own subprocess where the two previously coalesced. That is a real regression on macOS, Linux and native Windows, where `getLocalProjectWorktreeGitOptions` returns `{}` and both callers land on the identical key; on WSL they already differ by distro and never shared. So the annotated listing is now the graph listing plus annotation, rather than a parallel scan of its own: `listWorktrees` awaits `listWorktreeGraph` and annotates the rows it returns. Both soften a Git failure to `[]`, so they can share one listing; strict keeps its own because it must be able to reject. The two kinds ran Git twice before and now run it once, so the overlap case gets strictly faster instead of paying for the opt-out. An annotated scan holds two in-flight entries now (its own, plus the graph listing it shares). Keeping its own entry matters: `detectSparseCheckoutCached` dedupes revalidation but not the initial fill, so two concurrent badge readers sharing only the graph scan would both probe. Per-platform delta: - macOS/Linux: fewer probes on the three call sites; one `git worktree list` instead of two when a graph and an annotated scan overlap. - native Windows, no WSL: same, and the saved subprocess is the expensive half. - Windows + WSL: the largest win. The discarded probes were 9p round-trips re-paid cold after every worktree create/remove. - SSH/relay: none. `listRepoWorktreeGraph` returns through the same provider branch as `listRepoWorktrees` before reaching local Git. - folder workspaces: none. Both return the same synthetic folder worktree. Not in this change: - The badge listing itself. It still probes, still annotates, and still keys on the distro exactly as #17932 left it. - The remaining `listRepoWorktrees` callers. They read `isSparse`, or feed rows to something that does.	2026-09-01 20:19:56 -07:00
Neil	26dfa46aa9	fix(wsl): resolve sparse-checkout and diff-stamp gitdirs through the caller's distro (#17932) ... Two main-process `resolveGitDir` call sites dropped the WSL distro their caller already held, so they could only resolve a gitdir pointer whose spelling carries its own translation: a `//wsl.localhost/<Distro>/...` base, or a `/mnt/<letter>` drvfs pointer that maps to a drive letter on its own. The layout that needs the third case is a repo inside the distro's filesystem with its worktrees on the Windows drive. `git worktree list` reports the worktree as `/mnt/c/wt/x`, which the listing translates to `C:\wt\x` — a base that no longer names a distro — while the `.git` gitfile beside it points at `/home/me/repo/.git/worktrees/x`, which has no drive to derive. Win32 then treats that pointer as absolute and reads a path that names nothing: - `detectSparseCheckout` stats `info/sparse-checkout` under the fabricated path, always misses, and reports the worktree as non-sparse — no sparse badge, and the file list claims files that are not on disk. - `readWorktreeDiffStamp` reads HEAD under the same path, gets nothing, and returns null. Null is the safe answer ("cannot prove unchanged"), but it retires the settled-diff cache for every file in that worktree, so each diff respawns Git. Both callers already have the distro: the listing threads its `GitWorktreeExecOptions` to `annotateSparseCheckoutStatus`, on through `detectSparseCheckoutCached` (the annotation cache added by #17859) and its background revalidation probe, and finally to `detectSparseCheckout`; and `file-diff` already forwards its `GitRuntimeOptions` to `readWorktreeDiffStamp`, which now forwards it to `resolveGitDir` as well. `resolveGitMetadataPath` still prefers a UNC base's distro and still tries drvfs before the caller-named distro, so nothing that resolved before resolves differently. The cache hop matters twice over. It is the only remaining caller of `detectSparseCheckout`, so without threading it the fix would not reach the probe at all. And the cache is where the bug turns sticky. #17859 keyed entries on `repoPath` + `worktreePath` alone, on the reasoning that the distro is a property of the repo and so every read for a given `repoPath` carries the same one. That invariant does not hold. `listRepoWorktrees(repo)` is called with no options at all from the filesystem-auth root rebuild (`registered-worktree-roots-cache.ts`, reached from `ensureAuthorizedRootsCache` on any auth check with a dirty cache) and from the local worktree-ownership check in `filesystem-worktree-helpers.ts`. Both land on the *same* key as the distro-carrying listing, because `translateWslOutputPaths` derives the distro from the cwd spelling before falling back to `options.wslDistro`, so a UNC-spelled repo path yields the identical `C:\...` worktree row either way. Measured on Windows in one process, branch build: a distro-less read followed by a distro-carrying read reported the sparse worktree as non-sparse both times. So `wslDistro` now joins the cache key -- trimmed and lowercased, matching how the rest of the codebase compares distro names, and appended last so the repo-scoped prefix delete still matches every variant. The per-path invalidate becomes a prefix delete for the same reason, dropping every distro variant of a removed or moved worktree. Keying on it closes both halves of the defect. A correct caller can no longer be served an answer derived without the distro it supplied. And because the entry a reader reaches is now selected by the same distro it would re-probe with, `revalidateInBackground` can no longer re-derive a warm entry under weaker options -- which mattered on its own: a distro-less reader crossing the five-minute window would otherwise flip a correct `true` to `false`, and the resulting change notification runs the registered invalidator, clearing the whole repo's cache and re-probing every worktree cold, on a five-minute loop. Cost of the extra key dimension is bounded by the number of distinct distros a given repo is actually read under: one where a distro is threaded everywhere, two while the distro-less callers above still exist. Entries are still repo-scoped, and both clears already sweep by prefix. Per-platform delta: - macOS/Linux: no change. Guest-pointer translation is gated to win32 and a caller-named distro is ignored off Windows; no caller supplies one there, so the cache keys and probes exactly as before. - native Windows, no WSL: no change. `wslDistro` is undefined, so the resolver takes exactly the branches it took before and every read keys on the same empty distro component, so the cache behaves exactly as it did. - Windows + WSL, UNC-spelled worktree: no change. The base already names the distro and outranks the caller's. - Windows + WSL, drvfs-spelled worktree with a drvfs pointer: no change. The drive-letter derivation still runs first. - Windows + WSL, drvfs-spelled worktree with a non-drvfs pointer: the sparse badge appears and the settled-diff cache starts hitting. Both previously failed toward "not sparse" / "do not cache", so neither can now serve a stale answer, and the distro-less listings no longer share the badge's cache entry. - SSH/relay: none. Those paths return through the provider branch before reaching either function. - folder workspaces, GitLab: none. Neither is on these code paths. Not in this change: - `readRepoCommonDirFromDisk` (worktree-listing). Passing the distro there is inert: a repo root's `.git` is a directory, so the gitfile-pointer branch never runs, and when `repoPath` itself is guest-spelled the preceding `stat` already fails — which no `resolveGitDir` option can fix. - The two `findExistingWorktreeSymlinkPaths` calls on the removal paths. Both receive `registeredWorktree.path` from `listWorktreesStrict`, which already translates every row out of the guest namespace, so the distro would be a no-op. The `removeWorktreeLinkedPaths` unlink beside them is untranslated too, so a half-threaded fix would only move the refusal from Orca's preflight to `git worktree remove`. - An absolute `commondir` payload, which `resolveGitCommonDir` still resolves untranslated. Git writes that file relative in the layouts above, and the failure direction is unchanged. - Giving the two distro-less `listRepoWorktrees(repo)` callers a distro. Neither reads `isSparse` -- both use only `worktree.path` -- so the distro would buy them nothing they consume, while resolving a project runtime inside the filesystem-auth rebuild would put a call that throws on `repair-required` behind a catch that skips the whole repo's authorized roots. The cache key makes their reads harmless; skipping the annotation for callers that never read it is a separate, larger change. The third no-options call in `hosted-review.ts` is inside the `repo.connectionId` branch and returns through the SSH provider, so it never reaches this cache.	2026-09-01 04:25:19 -07:00
Neil	84584b61d0	perf(git): cache sparse-checkout annotation on worktree listing (#17859) ... * perf(git): cache sparse-checkout annotation on worktree listing `git worktree list` never reports sparse-checkout state, so every listing paid a per-worktree fs.stat + config read to detect it -- measured at ~9x the cost of the `git worktree list` call it decorates on a 1000-worktree repo. Cache the result per worktree path, invalidated by the existing worktree-change invalidator registry plus explicit remove/move hooks, with a 5-minute reconcile window bounding the one unwitnessed edge case (external `git sparse-checkout` toggle with extensions.worktreeConfig off), matching the precedent already accepted in readRepoWorktreeAdminFingerprint. * perf(git): normalize/scope sparse-checkout cache keys, add SWR Address independent-review follow-ups on the sparse-checkout annotation cache (#17859): - Extract canonicalWorktreePath() from areWorktreePathsEqual and key/invalidate the cache through it on both read and write, closing the disclosed path-spelling P2 outright instead of leaving it as a residual risk. - Scope cache entries and clears by repo path (derived from the invalidator registry's repoId via a store lookup, falling back to a full clear when the repo can't be resolved), so churn in one repo no longer evicts a sibling repo's warm cache. - Replace the hard 5-minute cutoff with stale-while-revalidate: past the window, callers get the cached value immediately while a deduplicated background probe corrects it and, on a flip, drives the existing worktrees-changed notification -- collapsing visible staleness from the full window to one refresh cycle at zero added listing latency. Also corrects a stale claim in the original PR description: newer Git does emit a `sparse` porcelain line (which annotateSparseCheckoutStatus already skips), but Orca's Git 2.25 compatibility baseline predates it, so the fallback detection this caches remains necessary. * fix(git): stop background sparse-checkout revalidation resurrecting invalidated entries Readiness-loop finding: a stale-while-revalidate probe in flight when a worktree is removed/moved (or a repo's cache is cleared) would still write its result back afterward, resurrecting an entry that was deliberately dropped. Guard the write with a presence check so an invalidated key stays absent until the next real read. * fix(git): identity-check the sparse-checkout SWR write-back guard The has()/presence guard from the previous commit only proved some entry existed at the key, not that it was the one this revalidation started from. A worktree removed and re-created at the same path while a background re-detect was in flight would repopulate the key with a fresh cold read, and the stale in-flight result would then overwrite it -- exactly the race greptile (P1) and pullfrog both flagged as still open. Compare the map's current entry by reference to the entry captured when the revalidation began; a mismatch means something else (invalidate, clear, or a fresh cold read) replaced it, and the stale result must not be written back. Added a regression test that fails against the old has() guard and passes with the identity check: invalidate and repopulate the key with a different value mid-flight, then let the stale revalidation settle and assert the fresh value survives.	2026-09-01 03:44:50 -07:00
Neil	1268fb56f1	fix(worktree): complete a create Git can confirm but cannot list (#17388) ... * fix(worktree): complete a create Git can confirm but cannot list `worktree.create` verified against `listWorktrees`, which softens every git failure to `[]`. Any listing failure therefore failed a create whose worktree and branch `git worktree add` had already written, orphaning both, and reported only 'Worktree created but not found in listing' — the real cause reached the main-process console and never the user. Verify against the error-propagating listing instead, and when that fails or omits the row, rebuild the row by asking Git about the worktree itself. The direct read returns nothing unless Git resolves the path into this repo's object store with the expected branch checked out, so an unrelated or half-made checkout still fails the create. Fixes #16520 * fix(worktree): authorize a recovered create and reject an unreadable HEAD Review follow-ups on the create-verification fallback: - register the recovered worktree's own root, additively, so the create the user just made is not rejected by filesystem/git-status IPC - treat an unreadable HEAD as no recovery instead of a blank OID - keep the direct read's failure when the listing merely omitted the row - skip the symlink cases on Windows and reset the new harness mock * fix(worktree): bound the create-recovery disk read and keep WSL paths case-sensitive Readiness-scan follow-ups: - deadline the filesystem common-dir read; a .git on a hung mount left the whole create IPC pending where it used to fail after the Git deadline - offer no disk candidate for a bare repo instead of a fabricated <repo>/.git - compare POSIX common dirs case-sensitively, so two WSL repos differing only in case are not accepted as one object store on a Windows desktop - move toGitOutputSpace to shared/wsl-paths as toWslExecutionSpace, next to the parseWslUncPath callers that already open-code it * fix(worktree): share one budget for create verification and keep recovered roots Three follow-ups from review of the create-recovery path: - The recovery no longer starts a fresh 30s deadline after the listing already burned one, so worst-case create verification stays at ~30s instead of ~60s. A 5s floor keeps the direct read a chance to answer when the listing spent the whole budget. - rebuildAuthorizedRootsCache now carries a repo's previously registered roots forward when its listing throws. A rebuild running while Git is still broken could otherwise un-authorize the worktree a create just recovered. - Corrected the scan-cache doc comment: it claimed strict and lenient listings coalesce, but the cache key includes the runner name precisely to keep them apart, so a strict joiner can never inherit a lenient scan's softened []. Each change has a negative control: reverting the hunk fails exactly its own test and nothing else. * fix(worktree): keep a recovered worktree authorized across roots-cache rebuilds The previous approach registered a recovered create into the same per-repo set the rebuild recomputes from `git worktree list`. That set is derived from the very listing that failed, so a rebuild would re-deny the worktree — either by overlapping the registration, or by simply listing again and omitting the row. Carrying old roots forward on a thrown listing did not cover either case. Recovered roots now live in their own additive layer that rebuilds union in rather than replace. The layer is retired on evidence, not on a timer: - the listing can see the worktree again (Git recovered), or - the listing succeeded and the directory is gone (worktree removed). A repo whose listing threw is left untouched, because a dead mount fails both the listing and the stat, and treating that as "removed" would revoke the worktree in exactly the outage this layer exists for. The layer is capped so it cannot grow unbounded, and survives cache invalidation deliberately: repo mutations are frequent and would otherwise re-deny a recovered worktree. Three tests cover the healthy-rebuild-omits-the-row case, the in-flight rebuild race, and retirement once the listing sees it again. Removing the union fails exactly the two keep-tests and nothing else. * perf(worktree): only read the repo's .git from disk when Git's own answer disagrees The disk read is a second opinion on Git's reading of the common dir, but it ran unconditionally as part of the same Promise.all. A deadline bounds the IPC, not the syscall: Promise.race cannot cancel an in-flight fs operation, and a `.git` on a hung mount (dead NFS/SSHFS, stalled WSL 9p) pins a libuv threadpool thread that no timeout can reclaim. AbortSignal would not help either — fsPromises.stat takes no signal, and a blocked syscall is not interruptible from userland. So stop paying it on the happy path: read from disk only when Git's own reading did not already confirm the common dir. Same accept/reject outcome, but the threadpool exposure now requires both a failed listing and Git disagreeing about the repo, instead of every recovered create. * fix(worktree): compare the disk common-dir witness in Git's execution space Exercising the fix on a real Windows host against WSL Ubuntu-24.04 found the filesystem second opinion is inert there. Node reads `.git` in the caller's space and answers `\\wsl.localhost\<Distro>\home\...\.git`, while Git-in-the- distro answers `/home/...`. isSameCommonDirPath refuses to compare a POSIX path against a Windows one, and canonicalizeLocalPath cannot bridge them because realpath on a Linux path from a Windows process is ENOENT. So the candidate could never match, and the one case that depends on this witness alone — a symlinked repo root on the Git 2.25 fallback — declined a worktree Git had already confirmed. Run the disk result through toWslExecutionSpace, the same translation readRepoLocation already uses. This is a false reject, not a false accept: it made recovery give up, never adopt the wrong repo. Verified on awin; the modern --path-format=absolute branch was unaffected because Git answers both sides itself there. * fix(worktree): retire a recovered root only on proof, never on a stalled probe The prune ran an unbounded stat and read every failure as removal. Two consequences, both in the outage the recovered layer exists for: a hung mount stalled the rebuild that gates filesystem auth, and a transient EACCES/EIO revoked a live worktree. The listingFailed guard did not cover either, because listWorktrees softens Git failures to [] and never throws. Prune now retires on definitive ENOENT only, probes in parallel under a deadline, and treats a stall as inconclusive. The capacity bound refuses a new root instead of evicting an authorized one, so an over-cap create is merely unauthorized rather than a live worktree being revoked.	2026-08-30 14:42:07 -07:00
Neil	3ab9766e38	perf(worktree): prepare checkouts while the composer is open ... Squashed merge of PR #17290.	2026-08-30 12:12:04 -07:00
Neil	037cc2e531	Split Git worktree responsibilities (#17253) ... * Split speech session lifecycle * Split terminal output scheduler pipeline * Split mobile browser pane modules * Prune resolved max-lines suppressions * Split pane tree equalization logic * Extract mobile troubleshoot screen styles * Split external automation manager * Split main window service attachments * Split hosted review creation checks * Split automation dispatch event handling * Split settings navigation metadata * Split daemon initialization lifecycle * Split GitLab item dialog * Split relay dispatcher layers * Split mobile host screen * Retarget mobile view settings source test * Split runtime file client layers * Split ports panel layers * Split runtime environments pane layers * Split local PTY provider responsibilities * Split CDP bridge responsibilities * Split relay Git handler responsibilities * Track moved relay Git fetch audit * Split Linear item drawer responsibilities * Split telemetry event schema responsibilities * Split resource usage status responsibilities * Split remote terminal multiplexer responsibilities * Split Git worktree responsibilities * Fix F3-speech for #17123 * Fix F1-cycle for #17131 * Fix F4-navtest for #17157 * Fix F2-allowlist for #17161	2026-08-29 20:20:55 -07:00