branching: the merge methods the orchestrator is told to use #171

Merged

emi merged 1 commit from docs/branching-merge-methods into dev

2026-08-02 01:06:43 +00:00

emi commented

2026-08-02 00:50:22 +00:00

Owner

.claude/BRANCHING.md told the orchestrator to merge with styles Forgejo now rejects — method="rebase" for feat/* → dev, and method="merge" for both promotions. Following it produces a 405. This is the runbook agents read before dispatching work, so a stale instruction here is a correctness bug.

The On fast-forward paragraph said adopting fast-forward-only "needs a one-time reconciliation of the protected branches, which is the owner's decision". That decision was taken and the reconciliation done (#164) — the trees were already identical, so it carried no content. release ⊆ main ⊆ dev now holds and promotions land the branches on the same SHA rather than merely the same tree.

The paragraph keeps its structural explanation of why divergence happened, because that is what makes the failure mode recognisable, and now points at reconciliation as the remedy instead of prescribing the merge commit that caused it.

Pairs with Centralis PR #28, which fixes the same contradiction in REPO_SETTINGS and promote.

`.claude/BRANCHING.md` told the orchestrator to merge with styles Forgejo now rejects — `method="rebase"` for `feat/*` → `dev`, and `method="merge"` for both promotions. Following it produces a 405. This is the runbook agents read before dispatching work, so a stale instruction here is a correctness bug. The **On fast-forward** paragraph said adopting fast-forward-only "needs a one-time reconciliation of the protected branches, which is the owner's decision". That decision was taken and the reconciliation done (#164) — the trees were already identical, so it carried no content. `release ⊆ main ⊆ dev` now holds and promotions land the branches on the same SHA rather than merely the same tree. The paragraph keeps its structural explanation of *why* divergence happened, because that is what makes the failure mode recognisable, and now points at reconciliation as the remedy instead of prescribing the merge commit that caused it. Pairs with Centralis PR #28, which fixes the same contradiction in `REPO_SETTINGS` and `promote`.

emi added 1 commit 2026-08-02 00:50:25 +00:00

branching: the merge methods the orchestrator is told to use

PR build (required check) / changes (pull_request) Successful in 14s

Details

secrets-guard / encrypted (pull_request) Successful in 10s

Details

shell-lint / shellcheck (pull_request) Successful in 11s

Details

PR build (required check) / build-backend (pull_request) Has been skipped

Details

PR build (required check) / build-frontend (pull_request) Has been skipped

Details

PR build (required check) / validate-observability (pull_request) Has been skipped

Details

PR build (required check) / gate (pull_request) Successful in 2s

Details

fd12ad6740

Forgejo now allows only squash and fast-forward-only, so the three method= calls
in this file named styles the API rejects: rebase for feat->dev, and merge
commits for both promotions. An orchestrator following them gets a 405.

The fast-forward paragraph said adopting ff-only 'needs a one-time
reconciliation of the protected branches, which is the owner's decision'. That
decision was taken and the reconciliation done — the trees were already
identical, so it carried no content. release subset-of main subset-of dev now
holds and promotions land the branches on the same SHA. The paragraph keeps the
structural explanation, since it is what makes the failure mode recognisable,
and now points at reconciliation as the remedy.