#1041 was never a squash. Verified on this repo: #1027, #1033 and #1032 have ONE parent and end with
(#N); #1041 has TWO and begins "Merge pull request". A merge commit's author is whoever created the
merge — ordinary git, not an anomaly. The rows differed by merge style, not by field, estate, path or
account state, and the discriminator was one field nobody had read: parent count.
Established with zero exceptions across four rows, two estates, two Gitea instances and three repos:
squash merge sets author = poster and committer = merger.
Of the three candidate discriminators I offered, merge path was correct and I had ranked it first. The
3-to-1 split was explicitly refused as a verdict, which is why the real answer stayed findable — a
majority reported as a conclusion would have closed the question on the wrong side.
And the resolution exposed a larger live problem, on THIS repo: mosaicstack/stack has
default_merge_style = "merge", with both styles enabled and both in live use. The default path produces
a merge commit, which attributes to the merger and loses authorship more completely than squash —
squash at least keeps the poster in author, a merge commit keeps nobody. Same configuration as the USC
repos, so this is not a USC problem. Merge style is itself load-bearing for attribution and must be
explicit, never defaulted.
Hard merge precondition for #1030: merged by the default path it becomes a merge commit and erases the
poster as well as all three branch authors. It must be merged with an explicit squash style. The three
prior deliveries are 1-parent only because merge-gate hardcodes {"Do":"squash"} — that fixed payload,
criticised on the message-field axis, is protective on this one because it cannot silently fall to the
repo default.
Also confirmed here: default_delete_branch_after_merge = False, so the RM-02 branch retention is not on
a timer.
Co-authored-by: tl-mosaic <[email protected]>
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
