Module worktree_rebase 

Batch-rebase a repository’s worktrees onto its remote default branch, fetching the remote exactly once per repository (issue #1400).

Keeping a fan-out of feature worktrees current with main otherwise means cd-ing into each one and running git fetch + git rebase origin/main by hand. Doing that naively re-fetches the remote for every worktree, which is both wasteful (N network round-trips) and subtly wrong: if origin/main advances between fetches, different worktrees rebase onto different tips and stop sharing a base. Linked worktrees share one object database, so a single git fetch <remote> <branch> updates the refs/remotes/<remote>/<branch> tracking ref every worktree already sees — which is exactly why “fetch once per repo, then rebase each onto that pinned ref” is the natural design.

Split of concerns (see ADR-0003 and ADR-0055). Every git read — enumerate the worktrees, resolve the onto ref, classify divergence / dirty / repo state — goes through git2. The two mutations, the fetch and the rebase, shell out to the user’s git: libgit2’s vendored build here has no reliable SSH transport (issue #903) and the shell inherits the user’s ssh-agent / ~/.ssh/config / credential-helper configuration for free, and git rebase brings full conflict handling, hooks, and --autostash.

Where it runs (ADR-0059, superseding ADR-0055 in part). This engine is host agnostic: it drives both the local CLI (omni-dev worktrees rebase) and the daemon’s two-phase rebase op. ADR-0055 originally confined it to the CLI on the premise that the daemon’s minimal environment lacked SSH_AUTH_SOCK and so could not authenticate a fetch. That premise was wrong — launchd exports SSH_AUTH_SOCK into the per-user session, so a LaunchAgent inherits the user’s ssh-agent. What the daemon genuinely lacks is a useful PATH, which is why the git binary is resolved through crate::git::resolve_git_binary rather than by name.

Structs

FetchOutcome

The one-shot fetch performed for a single repository.

Plan

The result of planning and (optionally) executing a batch rebase.

RebaseOptions

Knobs for a batch rebase.

WorktreeOutcome

What happened (or, in a dry run, would happen) to one worktree.

Enums

RebaseResult

The per-worktree classification and outcome.

Selection

Which worktrees a batch rebase should target.

SkipReason

Why a worktree was skipped rather than rebased.

Functions

execute

Executes a Plan, rebasing every RebaseResult::WouldRebase worktree.

plan

Plans a batch rebase, fetching each repository’s onto ref exactly once.