fix(worktree): fetch trunk before creating worktree to avoid stale base#2324
Draft
richardsolomou wants to merge 1 commit into
Draft
fix(worktree): fetch trunk before creating worktree to avoid stale base#2324richardsolomou wants to merge 1 commit into
richardsolomou wants to merge 1 commit into
Conversation
When the worktree base is created off the local trunk ref, a clone whose local default branch hasn't been refreshed produces a worktree that starts behind `origin/main`. The agent then iterates on stale code, which is the root cause behind the user-reported pattern of worktrees starting "behind master". Add an opt-in `fetchBeforeCreate` flag on the trunk path that fetches `origin/<base>` first and bases the worktree on the remote tip when reachable. Falls back to the local base ref if the fetch fails so offline / local-only setups still work and the user's local checkout stays untouched (we base off `origin/<branch>`, not a fast-forward of local `<branch>`). Wired up at the workspace-service trunk path; the occupied-branch fallback keeps local-base behavior so user-local commits aren't silently bypassed. Generated-By: PostHog Code
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Cloud-agent worktrees can start off a stale local trunk. When the harness provisions a clone whose local
mainhasn't been refreshed,WorktreeManager.createWorktreebases the new detached worktree on the local ref — so the agent begins iterating on code that's already behindorigin/main, surfacing user-visible "worktree starts behind master" reports.Changes
Add an opt-in
fetchBeforeCreateoption on the trunk path:WorktreeManager.createWorktree({ fetchBeforeCreate: true })calls a newresolveFreshBaseRefhelper that does a best-effortgit fetch origin <baseBranch>and bases the worktree onorigin/<base>when reachable. Falls back to the local base ref if the fetch fails (offline, noorigin, ref doesn't exist on the remote) so existing local-only setups still work.CreateWorktreeSagagets the same option for parity, usingthis.gitdirectly inside the existing write lock (thefetchquery helper would re-enter the lock and deadlock).apps/code/src/main/services/workspace/service.tspassesfetchBeforeCreate: trueon the trunk path only. The occupied-branch fallback (which bases off a user-local branch they may have committed to) is intentionally left as-is — fetching there would silently bypass their local commits.We base off
origin/<base>rather than fast-forwarding the local branch so the user's local checkout is never mutated; only the worktree picks up the remote tip.Two small helpers (
hasRef,fetchRef) added topackages/git/src/queries.tsto keep the saga andWorktreeManagersymmetric.How did you test this?
pnpm --filter @posthog/git test src/worktree.test.ts— 3 new tests pass:fetchBeforeCreate, worktree is based on the stale local ref (baseline that proves the bug).fetchBeforeCreate, worktree starts at the remote tip and localmainis not mutated.fetchBeforeCreateand an unreachable remote, falls back to the local base.pnpm --filter @posthog/git typecheck,pnpm --filter code typecheck,pnpm lint— all clean.forceRemoveEACCES,detectDefaultBranch > prefers remote HEAD) reproduce onmainand are unrelated.Publish to changelog?
no