3 Commits

Include renames

Author	SHA1	Message	Date
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	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	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