fix(repos): `madt_repos edit` lacks fast-forward-only + rebase-explicit merge flags and mislabels `allow_rebase_update` #432

New issue

Closed

opened 2026-08-17 18:54:19 +00:00 by hexajon · 0 comments

hexajon commented

2026-08-17 18:54:19 +00:00

Owner

Problem

Setting a repo to fast-forward-only merges is not expressible through madt_repos edit. Standing up signed-commit enforcement across the sixfold-space repos, the merge-style config had to go out as raw madt_api_call PATCH /repos/{owner}/{repo}.

Three concrete gaps in the madt_repos edit merge fields:

Missing allow_fast_forward_only_merge. There is no way to enable the fast-forward-only merge style. This is the only forge-side merge style that preserves an author signature, because it mints no new commit. So it is exactly what a require_signed_commits repo needs.
Missing allow_rebase_explicit (rebase then create a merge commit). The full Gitea merge-style set is not covered.
allow_rebase_update is mislabeled. Its description reads "Allow fast-forward-only merging". But allow_rebase_update is the Gitea flag for "update a PR branch by rebase", a different setting. Reaching for ff-only, this wrong param looks correct right up until the merge behaves differently.

Why it matters

require_signed_commits plus PR merges only works with fast-forward-only (or a locally-signed merge). Any other server-side style mints an unsigned commit that the branch rule then rejects. Enabling signing on the org repos needed default_merge_style: "fast-forward-only" plus allow_fast_forward_only_merge: true and the other styles off. madt_repos edit could not express that, so it went out as raw API.

Fix

Add allow_fast_forward_only_merge and allow_rebase_explicit to madt_repos edit.
Correct the allow_rebase_update description to its real meaning (update a PR branch by rebase), not fast-forward-only merging.
A short note that default_merge_style: "fast-forward-only" pairs with signed-commit enforcement would help the next person.

#431 - branch protection is undiscoverable from madt_repos; same shape of MCP-surface gap, and it drove the same raw-API fallback.
#424, #422, #392 - commit signing.

## Problem Setting a repo to fast-forward-only merges is not expressible through `madt_repos edit`. Standing up signed-commit enforcement across the sixfold-space repos, the merge-style config had to go out as raw `madt_api_call PATCH /repos/{owner}/{repo}`. Three concrete gaps in the `madt_repos edit` merge fields: 1. **Missing `allow_fast_forward_only_merge`.** There is no way to enable the fast-forward-only merge style. This is the only forge-side merge style that preserves an author signature, because it mints no new commit. So it is exactly what a `require_signed_commits` repo needs. 2. **Missing `allow_rebase_explicit`** (rebase then create a merge commit). The full Gitea merge-style set is not covered. 3. **`allow_rebase_update` is mislabeled.** Its description reads "Allow fast-forward-only merging". But `allow_rebase_update` is the Gitea flag for "update a PR branch by rebase", a different setting. Reaching for ff-only, this wrong param looks correct right up until the merge behaves differently. ## Why it matters `require_signed_commits` plus PR merges only works with fast-forward-only (or a locally-signed merge). Any other server-side style mints an unsigned commit that the branch rule then rejects. Enabling signing on the org repos needed `default_merge_style: "fast-forward-only"` plus `allow_fast_forward_only_merge: true` and the other styles off. `madt_repos edit` could not express that, so it went out as raw API. ## Fix - Add `allow_fast_forward_only_merge` and `allow_rebase_explicit` to `madt_repos edit`. - Correct the `allow_rebase_update` description to its real meaning (update a PR branch by rebase), not fast-forward-only merging. - A short note that `default_merge_style: "fast-forward-only"` pairs with signed-commit enforcement would help the next person. ## Related - #431 - branch protection is undiscoverable from `madt_repos`; same shape of MCP-surface gap, and it drove the same raw-API fallback. - #424, #422, #392 - commit signing.

hexajon referenced this issue

2026-08-17 21:15:01 +00:00

fix: 45 server-side merge commits on main carry the forge noreply identity, not jon@sixfold.space #436

hexajon referenced this issue

2026-08-17 22:07:53 +00:00

audit: sweep CLI flags, subcommands, and MCP arg/action names for name-vs-behavior mismatches #441

hexajon referenced this issue from a pull request that will close it,

2026-08-17 22:08:11 +00:00

feat(repos): add fast-forward-only and rebase-explicit merge flags and branch-protection cross-references #442

hexajon referenced this issue from a commit

2026-08-17 22:08:13 +00:00

feat(repos): add fast-forward-only and rebase-explicit merge flags; fix allow_rebase_update description; cross-reference branch protection (#431, #432)