rebase

# Rebase Rebase the current branch onto a base branch, resolving conflicts and verifying tests along the way. ## Step 0: Check for an in-progress rebase Before anything else, check whether a rebase is already underway: ```bash git rev-parse --git-path rebase-merge >/dev/null 2>&1 && ls "$(git rev-parse --git-path rebase-merge)" >/dev/null 2>&1 && echo "rebase in progress" || (ls "$(git rev-parse --git-path rebase-apply)" >/dev/null 2>&1 && echo "rebase in progress") ``` If a rebase is already in progress, skip Steps 1–2 entirely. Assume the task is to resolve the outstanding conflicts and continue the rebase: go straight to Step 3. Treat the base branch as the one already being rebased onto — you do not need to determine or fetch it. Otherwise, continue to Step 1. ## Step 1: Determine base branch Determine the base branch in this order: 1. Use `$ARGUMENTS` if the user specifies a branch 2. Use the tracked parent from `git config branch.$(git branch --show-current).parent`, if set and it still resolves to a commit 3. Use `bin/base-branch` if the script exists and is executable 4. Ask the user which branch to rebase onto ## Step 2: Start the rebase Fetch latest and begin the rebase: ```bash git fetch origin git rebase origin/<base-branch> ``` If the rebase completes with no conflicts, skip to Step 6. ## Step 3: Resolve conflicts 1. Identify the conflicting files with `git diff --name-only --diff-filter=U` 2. Read only the conflict hunks (`git diff -- <file>`) with enough surrounding lines to understand both sides of the conflict. Open the whole file only when the hunk alone doesn't make the intent clear. 3. Resolve the conflict by taking both sides into account — don't blindly pick one side. Understand the intent of each change and produce a result that incorporates both correctly. 4. Stage the resolved files with `git add` If a conflict is ambiguous and you can't confidently determine the correct resolution, ask the user. ## Step 4: Run related tests Run the tests related to the files that had conflicts in a sub-agent (Agent tool, `general-purpose`, `model: haiku`). Give it the test files to run and ask for only the verdict: pass, or the failing test names with their assertion messages — no log output, and no edits. If tests fail due to the conflict resolution, fix them before proceeding. If tests fail but seem **unrelated** to the rebase, have the same sub-agent verify by stashing and testing: ```bash git stash # run tests again git stash pop ``` - If tests also fail without your changes, the failures are pre-existing. Note this for the user and continue. - If tests only fail with your changes, the rebase introduced the problem. Investigate and fix. If you are unable to resolve test failures, let the user know what's broken and what you tried. ## Step 5: Continue the rebase ```bash git rebase --continue ``` If there are more conflicts, go back to Step 3. Repeat until the rebase is complete. ## Step 6: Update the tracked parent If a tracked parent is set for this branch (`git config branch.$(git branch --show-current).parent`), update it so later tooling stays in sync and doesn't act on a stale parent ref: ```bash branch=$(git branch --show-current) git config "branch.$branch.parent" "<base-branch>" git update-ref "refs/parent/$branch" "$(git rev-parse origin/<base-branch>^{commit})" ``` Skip this step if no tracked parent is set. ## Step 7: Check remote and compare If there is no remote tracking branch (`git rev-parse --verify @{u}` fails), skip this step and report that the rebase is complete. Otherwise reduce each branch's net change against the base to a normalized hash and compare. `<base-branch>` is the branch you just rebased onto, using the freshly fetched `origin/` ref for both sides: ```bash git diff -b --unified=0 origin/<base-branch>...HEAD | git patch-id --stable | awk '{print $1}' git diff -b --unified=0 origin/<base-branch>...@{u} | git patch-id --stable | awk '{print $1}' ``` `patch-id --stable` ignores line numbers, hunk headers, and file ordering, and `-b` ignores whitespace — so a rebase that adapted your change to overlapping base edits still matches. If the hashes match (including both empty), report **Clean rebase — no issues detected.** and stop. If they differ, list the affected files and stop there — do not write patch files or analyze hunks: ```bash git diff -b --unified=0 --name-only origin/<base-branch>...HEAD git diff -b --unified=0 --name-only origin/<base-branch>...@{u} ``` Report the file names and note that local and remote differ. Differing hashes are expected whenever the branches hold different commits — commits added since the last push, or a base that moved — so do not call it a problem on the hash alone. Investigate further only if the user asks.