|
| 1 | +# Exempt retarget-base-not-found from blocking retarget |
| 2 | + |
| 3 | +Date: 2026-04-10 |
| 4 | + |
| 5 | +## Context |
| 6 | + |
| 7 | +`arb retarget` applies an all-or-nothing gate: if any skipped repo has a non-exempt skip flag, the entire operation is blocked. The `retarget-base-not-found` flag fires when the old base branch is missing (neither remote nor local) and `status.base.ahead > 0`. The original intent was to block retarget when a repo has stacked work whose rebase boundary cannot be determined. |
| 8 | + |
| 9 | +However, `ahead` is measured against the fallback default branch (e.g., `main`), not the missing old base — because when the configured base is gone, base resolution falls back to the default branch. This means any feature branch with commits ahead of `main` triggers the flag, even when the old base branch was never present on that repo. In multi-repo workspaces where only some repos have the old base branch, this blocks the entire retarget unnecessarily. |
| 10 | + |
| 11 | +## Options |
| 12 | + |
| 13 | +### Exempt retarget-base-not-found |
| 14 | +Add the flag to `RETARGET_EXEMPT_SKIPS` alongside `no-base-branch` and `retarget-target-not-found`. |
| 15 | +- **Pros:** Simple one-line change. Follows the existing flat-set exemption pattern. Repos with this flag are already skipped (not operated on), so the exemption only controls whether they block other repos. |
| 16 | +- **Cons:** Does not distinguish "old base was never here" from "old base existed but was deleted." Both cases become non-blocking. |
| 17 | + |
| 18 | +### Split into two distinct flags |
| 19 | +Introduce `retarget-base-never-present` (exempt) and `retarget-base-deleted` (blocking) to preserve the safety distinction. |
| 20 | +- **Pros:** More precise safety model in theory. |
| 21 | +- **Cons:** The distinction cannot be reliably determined — when a branch is gone from both remote and local, there is no evidence of whether it was ever present. The `ahead` count is unreliable for this purpose (measured against fallback, not the missing base). Disproportionate complexity for no practical safety gain. |
| 22 | + |
| 23 | +## Decision |
| 24 | + |
| 25 | +Exempt `retarget-base-not-found` by adding it to `RETARGET_EXEMPT_SKIPS`. |
| 26 | + |
| 27 | +## Reasoning |
| 28 | + |
| 29 | +The exemption is safe because repos with this flag are already being skipped — they will not be rebased. The change only determines whether the skip also prevents other repos from being retargeted. After the retarget completes, the workspace config is updated to the new base, and the next `arb rebase` evaluates each repo freshly against the new base. |
| 30 | + |
| 31 | +The split-flag approach is not implementable without maintaining per-repo history of which branches have existed, and even if it were, the "deleted" case is equally safe to exempt for the same reason: the repo is skipped, not operated on. |
| 32 | + |
| 33 | +## Consequences |
| 34 | + |
| 35 | +- Multi-repo workspaces where only some repos have the old base branch can now be retargeted without manual intervention. |
| 36 | +- The `retarget-base-not-found` skip is still surfaced in the plan table (with attention styling via `BENIGN_SKIPS`), so the user sees which repos were skipped and why. |
| 37 | +- If a future scenario arises where a repo's stacked work truly depends on the deleted old base, the repo is still skipped — no data loss occurs. The user would need to manually resolve the branch state before rebasing that repo. |
0 commit comments