hive-forge: fix stale-branches comment/docs — hyperhive rebase+ff merges, not squash

This commit is contained in:
damocles 2026-08-28 17:09:38 +02:00 committed by mara
commit b8eb598329
2 changed files with 11 additions and 9 deletions

View file

@ -31,12 +31,12 @@ dimension directly.
- **Stale branches** - `hive-forge lint stale-branches --days <n>`
finds remote branches with no recent commits (skips branches that are
heads of open PRs) and reports each one's merge outcome (PR merged /
closed unmerged / no PR at all) — squash-merge ancestry can't tell
those apart, so don't delete a stale branch on the age alone; check
the verdict first. On a repo with enough PRs to exceed the verb's own
page cap, an old branch's outcome may come back "unknown" instead of
a verdict — that's not the same claim as "no PR", treat it as
"can't tell, don't delete" too.
closed unmerged / no PR at all) — hyperhive's rebase+ff merges mean
ancestry can't tell those apart, so don't delete a stale branch on the
age alone; check the verdict first. On a repo with enough PRs to
exceed the verb's own page cap, an old branch's outcome may come back
"unknown" instead of a verdict — that's not the same claim as "no PR",
treat it as "can't tell, don't delete" too.
## Using them as a sweep

View file

@ -286,9 +286,11 @@ fn run_stale_branches(client: &Client, args: StaleBranchesArgs) -> Result<()> {
// a closed one tells a surviving stale branch its actual fate —
// merged (branch is a leftover copy, safe to delete) vs. closed
// unmerged / never had a PR (the branch is the only copy). Because
// hyperhive squash-merges, a merged branch's tip is never an
// ancestor of main, so ancestry can't tell these apart; this is the
// only signal that can.
// hyperhive merges via rebase + fast-forward, the branch's commits
// are replayed onto main's current tip as new commits before main
// moves — so the original branch tip's SHA is never an ancestor of
// main even once merged, and ancestry can't tell these apart; this
// is the only signal that can.
// Whether the walk below hit `MAX_PAGES` without ever seeing a
// short page — i.e. there are more PRs than the cap fetched, so
// `latest_pr_by_head` is missing an unknown number of the oldest