> If rebased code is the same as merged code, yes, it was tested.
But that's the big "If". When I first started using git, the upstream maintainer use to rebase my changes into his tree. The problem I had was I never knew what changes he pulled. I would push out a patch series of commits but I never knew what patches actually made it upstream. This changed later when Linus told everyone how to do it, and my push requests were then merged.
The problem is that I can not check what patches I pushed actually made it into upstream. There were some cases that a patch or two was dropped, and I had no clue. It was dropped because of conflicts or someone questioned the patch. But because the other patches were rebased in, I had to go patch by patch to determine what was in and what was not, and this was very time consuming.
I totally understand the usefulness of git pull being a rebase, but it should not be the default. Could you imagine Linux if Linus rebased everyone's pull requests?