sixfold-space/madtea

SHA256

Fork 0

finish: when the forge refuses a merge for a signing reason, suggest fast-forward-only after its error #478

New issue

Open

opened 2026-09-09 22:24:58 +00:00 by hexajon · 1 comment

hexajon commented

2026-09-09 22:24:58 +00:00

Owner

Follow-up to #425 item 3. finish honors the target repo's default_merge_style. A fast-forward-only style mints no commit at all, so on such a repo the forge never has to sign anything. (A server-side rebase mints no merge commit, but it rewrites every commit and drops the author's own signature, so it is not a fix for signing.), and that is the state on this repo (every merge today landed with the default branch at the work commit's own sha). A repo whose base requires signed commits but whose default_merge_style is merge or rebase-merge still gets a server-side merge commit the forge signs with its own key or leaves unsigned.

Rescoped 2026-09-14

Decision: madtea does not refuse on its own here. The forge enforces its own signing rule. A forge with its own signing key produces a valid, signed merge commit, and madtea must work with that setup. A forge that cannot sign refuses the merge itself.

Ask: when the forge refuses a finish merge for a signing reason, keep the forge's error as it is (it is already surfaced verbatim) and add one suggestion after it: fast-forward-only creates no merge commit, so the forge has nothing to sign. Suggest only. Never change the merge style and never refuse before the forge does. No madtea-held key, per ADR 0013.

Acceptance

A merge the forge refuses for a signing reason shows the forge's error unchanged, followed by the one-line fast-forward-only suggestion.
Any other merge failure shows no signing suggestion.
finish never refuses a merge on its own for signing reasons, whatever the merge style.
The signing-reason match is taken from the forge's real refusal text (from a live probe or the forge source), not guessed, and a unit test pins it.

Refs #425, #424, ADR 0013.

Follow-up to #425 item 3. `finish` honors the target repo's `default_merge_style`. A fast-forward-only style mints no commit at all, so on such a repo the forge never has to sign anything. (A server-side rebase mints no merge commit, but it rewrites every commit and drops the author's own signature, so it is not a fix for signing.), and that is the state on this repo (every merge today landed with the default branch at the work commit's own sha). A repo whose base requires signed commits but whose `default_merge_style` is `merge` or `rebase-merge` still gets a server-side merge commit the forge signs with its own key or leaves unsigned. ## Rescoped 2026-09-14 Decision: madtea does not refuse on its own here. The forge enforces its own signing rule. A forge with its own signing key produces a valid, signed merge commit, and madtea must work with that setup. A forge that cannot sign refuses the merge itself. Ask: when the forge refuses a `finish` merge for a signing reason, keep the forge's error as it is (it is already surfaced verbatim) and add one suggestion after it: `fast-forward-only` creates no merge commit, so the forge has nothing to sign. Suggest only. Never change the merge style and never refuse before the forge does. No madtea-held key, per ADR 0013. ## Acceptance - A merge the forge refuses for a signing reason shows the forge's error unchanged, followed by the one-line `fast-forward-only` suggestion. - Any other merge failure shows no signing suggestion. - `finish` never refuses a merge on its own for signing reasons, whatever the merge style. - The signing-reason match is taken from the forge's real refusal text (from a live probe or the forge source), not guessed, and a unit test pins it. Refs #425, #424, ADR 0013.

hexajon added the

enhancement

label

2026-09-09 22:24:58 +00:00

hexajon referenced this issue

2026-09-09 22:29:10 +00:00

feat(git): pre-push signature guard gated on the target repo's require_signed_commits protection (#425 item 2) #479

hexajon referenced this issue

2026-09-14 18:47:24 +00:00

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

hexajon changed title from ~~finish: refuse or steer when the base requires signed commits and default_merge_style would mint an unsigned server-side merge commit~~ to finish: when the forge refuses a merge for a signing reason, suggest fast-forward-only after its error

2026-09-14 20:52:55 +00:00

hexajon added the

status/needs-verification

label

2026-09-14 20:53:35 +00:00

hexajon commented

2026-09-14 20:53:35 +00:00

Author

Owner

Parked: to build this I need the forge's real refusal text for a merge blocked by signing. Only a live probe can give that text (a throwaway repo that requires signed commits, with merge style merge). The acceptance criteria forbid guessing it.

Parked: to build this I need the forge's real refusal text for a merge blocked by signing. Only a live probe can give that text (a throwaway repo that requires signed commits, with merge style `merge`). The acceptance criteria forbid guessing it.

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

sixfold-space/madtea#478

No description provided.

Rows
Columns