fj pr merge ignores the repo's default_merge_style and forces style=merge #240
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
fj pr mergesendsstyle=mergewhen--styleis omitted, instead of therepo's configured
default_merge_style. On a repo that disallows merge commitsit fails outright; on a repo that allows both it silently produces the wrong
kind of history.
Reproduction
rasterstate/fleetdoes not allow merge commits:fjpickedmergeon its own; nothing on the command line asked for it.rasterstate/paragonallows both, and its configured default is squash:Merging there without
--stylestill builds a merge commit.Why it is worth more than a style nit
paragon has
require_signed_commitsondevelop. A merge commit brings the PRbranch's original commits onto the target, so branch protection inspects each of
them; a squash builds one new commit signed by the Forgejo instance key and the
contributor's own signature is never on that path. So the two styles differ in
whether a merge is possible, not just in how history looks:
Same PR, same commit, seconds apart. The only difference is the flag
fjsupplied for me.
That error message points at the contributor's signature, so the natural reading
is "this contributor's key is not trusted". It cost us real work tonight: I read
it that way, concluded four agent accounts needed their signing keys fixed, and
briefed all four to re-sign and force-push. One of them refused and produced the
counter-example. Another had already complied and discarded a green CI run plus
its review verdict, roughly 25 minutes of runner time, for a problem that did not
exist. The defaulted flag was the whole cause.
Expected
Omitting
--styleuses the repo'sdefault_merge_style.gh pr mergebehavesthis way, and it is what the field is for.
Suggested fix
Read
default_merge_stylefrom the repo object and use it when--styleisabsent. If that field is somehow unavailable, prefer failing with "no --style
given and the repo default could not be read" over silently choosing one, since
the wrong choice is not always visible as an error.
Secondary, worth fixing either way: when the server rejects a push because a
commit is unverified, the message reads as a statement about the contributor. It
would be much less misleading if it named the merge style in play, e.g. "style
'merge' places the branch's own commits on develop, which requires each to be
signed by a verified key; 'squash' does not."