> I find it cleaner that work is found associated to one sha on the hardest
> > branch, and we treat (or should be) CI holistically across branches.
>
> If we -s ours and amend merge commits on things that straddle stuff like
> 8099, MS rewrite, Simulator, guardrails, etc, then we have multiple SHA
> where the impl for a thing took place and N of them (N being count of newer
> branches than oldest where it applies) where they're hidden inside a merge
> commit right?
>
That patches can be significantly different across branches is inavertible.
One original commit versus individual commits on each branch is a trade-off
between cleaner git history and github fancies with more direct commits.
Taking it further, patches to release branches should be as minimal as
possible. It makes sense that such bug tickets are incentivised to be
minimal, and if there is a smarter way (improvement) in trunk that is a
separate follow-up ticket and patch.
So… I am willing to say (for now) that I like it that merge shas have the
connection to the original singular shas on the hardest branch, and that we
have a more concise git history (one ~third the merge commits).
> Also, nothing's keeping us from treating CI holistically and pushing
> --atomic across multiple branches even if we don't have merge commits.
> That's just a procedural question we could agree on and adhere to.
>
Sure, but atomic is not the same: it's manual adherence and there's no
history/record of it.
