Skip to content

v0.8.61: Add post-merge branch hygiene checks for release and scratch branches #3214

@Hmbown

Description

@Hmbown

Problem

After the v0.8.60 website/readme work landed, the local checkout was still on renovate/website-and-readmes, even though HEAD matched origin/main, origin/codex/v0.8.60, and tag v0.8.60. The remote origin/renovate/website-and-readmes also remained behind the final release tip. That makes it look like the work may not have merged, even when the commits are already present on the release/main refs.

Live repro on 2026-06-14:

HEAD / origin/main / origin/codex/v0.8.60: ae101a123
local branch: renovate/website-and-readmes
origin/renovate/website-and-readmes: 652d3925a
local codex/v0.8.60: 1574dd488, behind origin/codex/v0.8.60 by 17 commits

Desired outcome

Release and scratch branch cleanup should make it obvious where the current release tip lives, and should avoid leaving merged work parked under a stale feature-branch name.

Acceptance criteria

  • Add a release hygiene check or runbook step that verifies the current checkout branch, local release branch, remote release branch, and main all point where expected after a release/integration merge.
  • Detect local branches whose HEAD is already contained in origin/main or the release branch and recommend safe cleanup.
  • Detect remote scratch/renovate/integration branches that are behind the final release tip and should be deleted or explicitly kept.
  • After v0.8.61 work lands, codex/v0.8.61 should be fast-forwarded locally and the working checkout should not remain on an unrelated scratch/renovate branch.
  • Document the exact cleanup commands, including a dry-run mode, so agents do not guess or delete branches blindly.

Notes

This is mostly maintainer UX, but it matters because a stale branch name creates release anxiety and makes it harder for contributors/helpers to tell whether their website/readme work actually landed.

Branch pruning policy

As part of the v0.8.61 cleanup, prune as many old local and remote branches as safely possible. The default should be to delete stale maintainer/scratch/renovate/codex branches once their tips are contained in origin/main, the active release branch, or an explicitly kept integration branch.

Keep branches that contain unique contributor work, especially work from people other than Hunter, until that work has been reviewed, merged, harvested with credit, or explicitly marked as preserved elsewhere. For those branches, the cleanup report should name the branch, the unique commits, the contributor(s), and the reason it was kept.

Additional acceptance criteria:

  • Produce a dry-run branch-prune report before deleting anything.
  • Separate safe deletes from keep/review decisions.
  • Never delete a branch with unique non-Hunter contributor commits unless the work is already merged, credited, or intentionally preserved in another branch/PR/issue.
  • After cleanup, report how many branches were deleted, how many were kept for contributor work, and which branches still need a human decision.

Metadata

Metadata

Assignees

No one assigned

    Labels

    documentationImprovements or additions to documentationenhancementNew feature or request

    Projects

    Status
    In progress

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions