From 2759d0744735554c02fcc426a724c4b985e7dadd Mon Sep 17 00:00:00 2001 From: Nils Lehnen <30603423+iderex@users.noreply.github.com> Date: Tue, 1 Sep 2026 11:08:14 +0200 Subject: [PATCH] Read the merge-method restriction against the live ruleset The parity walk's parameter table gave `allowed_merge_methods` the value `["merge","squash","rebase"]` and a verdict of "Change owed", and the subsection under it said in as many words that the restriction is not in place and that the only thing standing against a squash is whoever picks the button. The parameter reads `["merge"]` now: gh api repos/Flowfin/lab/rules/branches/main \ --jq '.[] | select(.type=="pull_request") | .parameters.allowed_merge_methods' ["merge"] Both statements were correct when they were written and stopped reproducing when the setting was edited. What that prevents is the reading a stale gap invites: a document whose subject is what stands behind a merge, describing an open hole that has been closed, in the one row of the table a reader is most likely to act on. The reason for the restriction stays here rather than moving to the issue that asked for it, because the parameter lives on a ruleset that is not in this tree and carries no comment of its own, so this section is the only place a reader who finds `["merge"]` can learn why. What is added beside it is the bound: no check here reads the parameter, a run stays green whichever way it is set, and switching it back is one edit. Three further sentences resting on the older value are repaired in the same pass. The table's preamble said all but the first row held the same value on both boards, and all nine do now. The row itself says which value moved and when. The signature subsection called `allowed_merge_methods` the only ruleset edit this document asks for, and the one it still asks for is the required status checks issue #26 assembles. Refs #55 Signed-off-by: Nils Lehnen <30603423+iderex@users.noreply.github.com> --- docs/quality-parity.md | 53 +++++++++++++++++++++++++++++++++--------- 1 file changed, 42 insertions(+), 11 deletions(-) diff --git a/docs/quality-parity.md b/docs/quality-parity.md index e317e69..047ff77 100644 --- a/docs/quality-parity.md +++ b/docs/quality-parity.md @@ -750,10 +750,12 @@ requires it to stay empty, so nothing here adds a second rule about it. ### The pull-request rule, parameter by parameter Every parameter the third command prints, with the target's value beside it. On -2026-08-10 all but the first held the same value on both boards, and that is -still the reading on 2026-08-21. A setting left at its default and a setting -chosen deliberately look identical afterwards, which is why every row carries a -reason and not only a verdict. +2026-08-10 all but the first held the same value on both boards, and that stayed +the reading through 2026-08-30. Re-read on 2026-09-01 all nine hold the same +value on both boards, because the first row is the one that moved and it moved +towards the target. A setting left at its default and a setting chosen +deliberately look identical afterwards, which is why every row carries a reason +and not only a verdict. The table listed eight rows and the command prints nine names. Which of the two that is, a parameter the platform started printing after the table was written @@ -762,7 +764,7 @@ below is the one that was absent either way. | Parameter | Here | Target | Verdict | | --- | --- | --- | --- | -| `allowed_merge_methods` | `["merge","squash","rebase"]` | `["merge"]` | Change owed. This is the one deviation in this walk worth closing rather than reasoning away, and the reason is below. | +| `allowed_merge_methods` | `["merge"]` | `["merge"]` | Changed here, and it is the only row in this table whose value has ever moved. It read `["merge","squash","rebase"]` at every reading of this walk from 2026-08-10 to 2026-08-30, which is why the subsection below is longer than a row that agrees usually needs: the reason for the restriction lives there because the parameter itself can carry none. | | `required_approving_review_count` | `0` | `0` | Kept. A count above zero on a board where I am the only reviewer refuses every merge, and a rule nobody can satisfy is switched off in a hurry rather than met. | | `dismiss_stale_reviews_on_push` | `false` | `false` | Kept. It only bites where a review is required, and none is required at a count of zero. | | `require_last_push_approval` | `false` | `false` | Kept, for the reason in the row above. | @@ -788,10 +790,37 @@ were rewritten by the merge that landed them is a pointer the receiving board cannot follow. Restricting the methods to `["merge"]` is what keeps a named commit resolvable. -The restriction is not in place. The third command above still prints all three -methods on this board, so a squash or a rebase merge here can break a record of -either kind, and the only thing standing against it today is whoever picks the -button. Issue #55 holds the change. +The restriction is in place. Read on 2026-09-01: + +``` +gh api repos/Flowfin/lab/rules/branches/main \ + --jq '.[] | select(.type=="pull_request") | .parameters.allowed_merge_methods' +["merge"] +``` + +WHAT STOOD HERE SAID THE RESTRICTION WAS NOT IN PLACE, and named the only thing +standing against a squash as whoever picks the button. That was the reading at +every earlier date in this walk and it stopped reproducing when the parameter was +edited. It is the same class the subsection below is about, arriving in the +direction that flatters nobody: a document describing a live setting goes wrong +whichever way the setting moves, and a stale sentence claiming a gap that has +been closed is as wrong as a stale sentence claiming a gap that has not. + +The two paragraphs above are the reason, and this is where they live rather than +only in the issue that asked for the edit. `allowed_merge_methods` is a parameter +on a ruleset that is not in this tree, nothing beside it holds a comment, and a +platform setting carries no argument for itself, so a reader who finds `["merge"]` +and wants to know why it is not the default set has this section and nothing else. +Restoring `squash` or `rebase` breaks record 0004's removal line and record 0005's +promotion range, both of which name a commit in this repository that survives only +where the merge does not rewrite it. + +It is a setting rather than a mechanism, which is the bound this whole document +carries and which this row does not escape. No check in this tree reads +`allowed_merge_methods`, a run here stays green whichever way it is set, and the +edit that restored the other two methods would take about as long as the one that +removed them. What refuses a squash today is the platform, and what would notice +it being switched back is somebody re-running the command above. ### The rule both boards carry now, and the condition it arrived ahead of @@ -918,8 +947,10 @@ contributor who holds none, and record 0023 says in as many words that it decides a signature is required and does not decide what happens to somebody with no key. Whether the setting should stand at all is still not a question this walk takes, and it is not one this document can answer: the ruleset is not -in this tree, and `allowed_merge_methods` remains the only ruleset edit this -document asks for. +in this tree. The only ruleset edit this document still asks for is the required +status checks issue #26 assembles. `allowed_merge_methods` was the other one and +has been made, which the row above and the subsection under the table both read +against the live parameter rather than against the sentence that stood here. A rule that is configured is not a rule this tree refuses, and that is the half of this section a reader is most likely to collapse in the other direction now.