I have to treat it as history now, because it's in my trunk. If it turns out to represent a test failure, then I don't want it in my trunk, but it's too late. Even though we waited for CI and only merged when the suite was green, we wound up with a failure in the trunk, because of the surprise merge conflict that got resolved after testing had already been performed. Neither parent head can be tested by itself to prove that the merge will pass all the tests. So unless you're pushing that feature branch up with the merge in it preemptively, before it merges back, then I don't know how your approach can fulfill this requirement. (If you do, then you'll wind up with twice as many merges, many of them with the shape of an octopus or multi-parent. IMHO this greatly hinders traceability and readability in the commit history, absolutely by enough to want to edit it out. Nobody is going to read that.)
I'm coming at this from my angle as a team lead, or mediator between novice contributors who are both pointing the finger at each other. If the two parent branches both passed, but the merge fails, and both upstream committers are gone, I no longer can have only one throat to choke. I have to check out both branches and confer with both contributors in order to resolve the conflict again.
One contributor or the other has broke the build. It will require additional investigation to decide which. If one branch has merged first, and the other second after rebase, then I never have this problem, and my debugging process has only one throat to choke. Delegation becomes much easier.
Whoever won the race to get their PR approved and merged first is not the one at fault. (This is the greatest incentive to get your stuff tested and merged, also!) The branch that has been rebased on the other one, then, must be at fault, because his merge came later. It's not a value judgement on a person, I am just keeping it simple. My one and only motivation for operating this way is to have 100% certainty that contributors' PRs which (we) have decided to merge after reviewing the test outcomes, are the same, so that all the intensive testing we performed and spent our time reviewing before the merges will not have been a waste.
I generally don't want merges in my feature branches, and I don't think you will convince me to want otherwise. But I appreciate you having engaged me in this debate. Every time I get to talk about my strongly held beliefs, I get a better perspective on why someone else might disagree. :+1:
My teams have usually been very small, and I can't say for sure that my strategy can scale. But we have scaled it successfully past 2 and into 4 developers. It requires everyone's cooperation, but once we have it this delegation subjectively seems about a thousand percent more reliable.