A merged PR still accepts pushes and shows the new head, so follow-up commits vanish silently #1136

New issue

Open

opened 2026-08-19 01:35:59 +00:00 by coilyco-ops · 0 comments

coilyco-ops commented

2026-08-19 01:35:59 +00:00

Member

What happened

#1132, on 2026-08-18:

21:45:29Z - PR opened at commit e815e463.
21:48:06Z - merged, two and a half minutes later, as merge commit 4b6a6674.
21:57:36Z - c326bf8a pushed to the same branch. Accepted.
22:30:07Z - b1831a48 pushed to the same branch. Accepted.

The PR record now reports head sha: b1831a48. Neither c326bf8a nor b1831a48 is an ancestor of 4b6a6674. git merge-base --is-ancestor says NO for both. 4b6a6674 contains only the first commit's 290 lines.

Anyone reading #1132 today sees a merged PR whose head is b1831a48 and would reasonably conclude that commit is on main. It is not.

The cost

The lost commits renamed a composed skill so it would stop matching the design role's "*design*" glob. Downstream, sirens-echo#985 named the renamed skill in its allowlist and went red with pattern "tooling-sirens-dowel-temporal-brand" matches nothing, because the rename never landed. That took a fresh PR (#1135) to reapply, and in the meantime main carried a mis-scoped skill reaching every design bundle.

Diagnosis cost more than the fix. The obvious reading was that the merge dropped the commits, and the actual cause is a race that leaves no trace on the PR page.

Why the existing rules do not cover it

AGENTS.md has A pushed branch owes its pull request, which governs opening one. Nothing governs the window after it opens. On a fast-merging lane a PR can close while its author is still working, and the author's own git push reports success.

Suggestions

Cheapest first:

An agent rule. Before pushing a follow-up to a branch with an open PR, confirm the PR is still open. If merged, branch from the new main and open a fresh PR rather than pushing.
A push-time guard. A pre-push hook that refuses a push to a branch whose PR is merged, or warns loudly. This is the only option that catches a human doing it.
A review-time note. Worth checking whether Forgejo can be configured to delete the head branch on merge, which turns the silent push into a failed one. default_delete_branch_after_merge is already true on this repository, so it is worth understanding why the branch survived and accepted writes.

The third is the real fix if it works, because it converts a silent success into a loud failure at exactly the right moment.

#1134 - the "*design*" glob whose over-selection made the lost rename necessary.
sirens-echo#985, #1135 - the downstream breakage and the reapply.

Work can be pushed to a branch whose pull request has already merged. Forgejo accepts the push, updates the PR's displayed head sha, and closes nothing. The commits reach the remote and never reach `main`, and the PR page then shows a head that was never merged. ## What happened #1132, on 2026-08-18: * `21:45:29Z` - PR opened at commit `e815e463`. * `21:48:06Z` - **merged**, two and a half minutes later, as merge commit `4b6a6674`. * `21:57:36Z` - `c326bf8a` pushed to the same branch. Accepted. * `22:30:07Z` - `b1831a48` pushed to the same branch. Accepted. The PR record now reports `head sha: b1831a48`. Neither `c326bf8a` nor `b1831a48` is an ancestor of `4b6a6674`. `git merge-base --is-ancestor` says NO for both. `4b6a6674` contains only the first commit's 290 lines. Anyone reading #1132 today sees a merged PR whose head is `b1831a48` and would reasonably conclude that commit is on `main`. It is not. ## The cost The lost commits renamed a composed skill so it would stop matching the design role's `"*design*"` glob. Downstream, sirens-echo#985 named the renamed skill in its allowlist and went red with `pattern "tooling-sirens-dowel-temporal-brand" matches nothing`, because the rename never landed. That took a fresh PR ([#1135](https://forgejo.coilysiren.me/coilyco-flight-deck/agentic-os/pulls/1135)) to reapply, and in the meantime `main` carried a mis-scoped skill reaching every design bundle. Diagnosis cost more than the fix. The obvious reading was that the merge dropped the commits, and the actual cause is a race that leaves no trace on the PR page. ## Why the existing rules do not cover it `AGENTS.md` has **A pushed branch owes its pull request**, which governs opening one. Nothing governs the window after it opens. On a fast-merging lane a PR can close while its author is still working, and the author's own `git push` reports success. ## Suggestions Cheapest first: 1. **An agent rule.** Before pushing a follow-up to a branch with an open PR, confirm the PR is still open. If merged, branch from the new `main` and open a fresh PR rather than pushing. 2. **A push-time guard.** A pre-push hook that refuses a push to a branch whose PR is merged, or warns loudly. This is the only option that catches a human doing it. 3. **A review-time note.** Worth checking whether Forgejo can be configured to delete the head branch on merge, which turns the silent push into a failed one. `default_delete_branch_after_merge` is already `true` on this repository, so it is worth understanding why the branch survived and accepted writes. The third is the real fix if it works, because it converts a silent success into a loud failure at exactly the right moment. ## Related - #1134 - the `"*design*"` glob whose over-selection made the lost rename necessary. - [sirens-echo#985](https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/pulls/985), [#1135](https://forgejo.coilysiren.me/coilyco-flight-deck/agentic-os/pulls/1135) - the downstream breakage and the reapply.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

coilyco-flight-deck/agentic-os#1136

No description provided.

Rows
Columns