hive-forge: precise wording on stale-branches rebase+ff ancestry claim

This commit is contained in:
damocles 2026-08-28 17:13:23 +02:00 committed by mara
commit f5a4e380c9

View file

@ -285,12 +285,12 @@ fn run_stale_branches(client: &Client, args: StaleBranchesArgs) -> Result<()> {
// head isn't "stale", it's "in review" (skip-list, as before), and // head isn't "stale", it's "in review" (skip-list, as before), and
// a closed one tells a surviving stale branch its actual fate — // a closed one tells a surviving stale branch its actual fate —
// merged (branch is a leftover copy, safe to delete) vs. closed // merged (branch is a leftover copy, safe to delete) vs. closed
// unmerged / never had a PR (the branch is the only copy). Because // unmerged / never had a PR (the branch is the only copy). hyperhive
// hyperhive merges via rebase + fast-forward, the branch's commits // merges via rebase + fast-forward: a branch needing an actual
// are replayed onto main's current tip as new commits before main // rebase gets its commits replayed with new SHAs before main moves,
// moves — so the original branch tip's SHA is never an ancestor of // so its original tip is usually no longer an ancestor — though a
// main even once merged, and ancestry can't tell these apart; this // branch that needed no rebase (already current) still is. Ancestry
// is the only signal that can. // therefore answers inconsistently, which is why this map exists.
// Whether the walk below hit `MAX_PAGES` without ever seeing a // Whether the walk below hit `MAX_PAGES` without ever seeing a
// short page — i.e. there are more PRs than the cap fetched, so // 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 // `latest_pr_by_head` is missing an unknown number of the oldest