Fail loud when pushing to a branch whose PR already merged #1034

New issue

Closed

opened 2026-08-12 23:40:14 +00:00 by coilyco-ops · 0 comments

coilyco-ops commented

2026-08-12 23:40:14 +00:00

Member

The hazard

Push commits to a branch whose PR already merged and git says nothing. The
push succeeds, the branch fast-forwards, no PR points at it, and the work is
stranded on a dead branch that looks pushed.

Three of the four repos keep merged branches around
(coilyco-flight-deck/infrastructure#807),
so the branch is still there to push to and nothing objects.

Wanted

A pre-push hook in the catalog suite that refuses the push when the branch it
is pushing has a merged PR, and says which PR.

The pre-push stage is already in use across the fleet, so this needs no new
machinery: agentic-os-kai, agentic-os-hardware, and infrastructure all declare
stages: [pre-commit, pre-push] today.

A local-only check will not work

The obvious cheap version is "is the branch tip already an ancestor of main".
It misses squash and rebase merges, which these repos allow and use.

Concretely, #1030
merged as 8186344f, and its branch commit 91113830 is not an ancestor
of that. I checked during that session and the ancestor test returned false on
a genuinely merged branch. Any hook built on it would have passed the exact
case it exists to catch.

So the check has to ask Forgejo whether a PR with this head branch is merged.

It must fail open on an unreachable Forgejo

This puts a network round trip in front of every push. The fleet has already
been bitten by mandatory network calls in the hook path, which is what
coilyco-bridge/deploy#402 was about.

A hook that blocks every push whenever Forgejo is briefly unreachable is worse
than the problem it solves. It should fail open on a network error or a missing
token, and refuse only on a definite merged-PR answer. That trades some
coverage for not being able to wedge the fleet, which is the right way round.

Check Ward first

Ward owns the pull-request-and-merge workflow and its broker, so it may
already guard this. Worth confirming before writing a hook, since the guard may
belong there instead.

Rollout

Authoring here, per the repo rule: the validator plus its
.pre-commit-hooks.yaml entry. The fleet rollout is an ansible role in
infrastructure, never install-time mutation from this repo.

## The hazard Push commits to a branch whose PR already merged and git says nothing. The push succeeds, the branch fast-forwards, no PR points at it, and the work is stranded on a dead branch that looks pushed. Three of the four repos keep merged branches around (https://forgejo.coilysiren.me/coilyco-flight-deck/infrastructure/issues/807), so the branch is still there to push to and nothing objects. ## Wanted A pre-push hook in the catalog suite that refuses the push when the branch it is pushing has a merged PR, and says which PR. The `pre-push` stage is already in use across the fleet, so this needs no new machinery: agentic-os-kai, agentic-os-hardware, and infrastructure all declare `stages: [pre-commit, pre-push]` today. ## A local-only check will not work The obvious cheap version is "is the branch tip already an ancestor of main". It misses squash and rebase merges, which these repos allow and use. Concretely, https://forgejo.coilysiren.me/coilyco-flight-deck/agentic-os/pulls/1030 merged as `8186344f`, and its branch commit `91113830` is **not** an ancestor of that. I checked during that session and the ancestor test returned false on a genuinely merged branch. Any hook built on it would have passed the exact case it exists to catch. So the check has to ask Forgejo whether a PR with this head branch is merged. ## It must fail open on an unreachable Forgejo This puts a network round trip in front of every push. The fleet has already been bitten by mandatory network calls in the hook path, which is what https://forgejo.coilysiren.me/coilyco-bridge/deploy/issues/402 was about. A hook that blocks every push whenever Forgejo is briefly unreachable is worse than the problem it solves. It should fail open on a network error or a missing token, and refuse only on a definite merged-PR answer. That trades some coverage for not being able to wedge the fleet, which is the right way round. ## Check Ward first Ward owns the `pull-request-and-merge` workflow and its broker, so it may already guard this. Worth confirming before writing a hook, since the guard may belong there instead. ## Rollout Authoring here, per the repo rule: the validator plus its `.pre-commit-hooks.yaml` entry. The fleet rollout is an ansible role in infrastructure, never install-time mutation from this repo.

coilyco-ops referenced this issue from coilyco-flight-deck/infrastructure

2026-08-12 23:40:40 +00:00

Converge default_delete_branch_after_merge, which is on for one repo and off for the rest #807

coilyco-ops added the

labels

2026-08-17 02:36:03 +00:00

coilyco-ops referenced this issue

2026-08-17 02:40:33 +00:00