Problem
aether agent --repo owner/name can start a new worktree from the cached mirror's current branch instead of the remote repository's default branch. A successful fetch is reported as fresh, so the wrong base looks verified.
On main at 67cb640, refreshMirror runs git fetch --prune origin and resolves FETCH_HEAD. cmdCode uses that SHA as the worktree start point. FETCH_HEAD follows the fetched branch selected for merge in the local clone; it does not identify the remote default branch.
Reproduction
In an isolated local Git fixture, I created a bare remote with default branch main and another branch feature, cloned it as a mirror, switched the mirror to feature, then ran git fetch --prune origin. git rev-parse FETCH_HEAD returned the feature commit (3090092), while origin/main was 33b624b and origin/HEAD pointed to main. The current function would mark the feature SHA fresh and pass it to createWorktree.
This can affect any reused --repo mirror whose local checkout has moved away from the remote default branch. The normal fresh-clone path is not the reproduction.
Expected behavior
A --repo run starts from the remote's current advertised default branch, or refuses to start when that branch or its fetched commit cannot be established. The printed base SHA matches the new worktree's parent.
Acceptance criteria
- Resolve the remote's advertised default branch for each reuse, fetch and verify that exact branch, and use its commit as
remoteTip. Do not infer the default from FETCH_HEAD, local HEAD, or a potentially stale origin/HEAD alone.
- If the default branch or commit cannot be verified (including offline/auth failures), return
unknown and keep the existing fail-closed --repo behavior.
- Add a real multi-branch Git fixture: mirror checkout on
feature, remote default on main; the worktree base and reported SHA must be main.
- Cover a remote default-branch change and a failed fetch. Keep refresh free of checkout, reset, merge, or clean operations on the mirror.
Scope
This is base selection for --repo runs. It does not change how a user-selected local --worktree run chooses its base.
Problem
aether agent --repo owner/namecan start a new worktree from the cached mirror's current branch instead of the remote repository's default branch. A successful fetch is reported asfresh, so the wrong base looks verified.On
mainat67cb640,refreshMirrorrunsgit fetch --prune originand resolvesFETCH_HEAD.cmdCodeuses that SHA as the worktree start point.FETCH_HEADfollows the fetched branch selected for merge in the local clone; it does not identify the remote default branch.Reproduction
In an isolated local Git fixture, I created a bare remote with default branch
mainand another branchfeature, cloned it as a mirror, switched the mirror tofeature, then rangit fetch --prune origin.git rev-parse FETCH_HEADreturned thefeaturecommit (3090092), whileorigin/mainwas33b624bandorigin/HEADpointed tomain. The current function would mark the feature SHAfreshand pass it tocreateWorktree.This can affect any reused
--repomirror whose local checkout has moved away from the remote default branch. The normal fresh-clone path is not the reproduction.Expected behavior
A
--reporun starts from the remote's current advertised default branch, or refuses to start when that branch or its fetched commit cannot be established. The printed base SHA matches the new worktree's parent.Acceptance criteria
remoteTip. Do not infer the default fromFETCH_HEAD, localHEAD, or a potentially staleorigin/HEADalone.unknownand keep the existing fail-closed--repobehavior.feature, remote default onmain; the worktree base and reported SHA must bemain.Scope
This is base selection for
--reporuns. It does not change how a user-selected local--worktreerun chooses its base.