I'm reading from the repo and I'm a little dumbfounded what's the innovation. > SubmitQueue speculatively rebases and validates multiple changes in parallel ag

I'm reading from the repo and I'm a little dumbfounded what's the innovation. > SubmitQueue speculatively rebases and validates multiple changes in parallel against predicted future states of HEAD. When validations pass, changes land automatically. When they fail, SubmitQueue isolates the offending change and retries the rest — all without human intervention. This seems to be a feature of GitHub (We have it in an old enterprise server installation) that does the same thing: > When a pull request is added to the merge queue, the changes in the pull request are grouped into a merge_group with the latest version of the base_branch as well as changes from pull requests ahead of it in the queue. GitHub will merge all these changes into the base_branch once the checks required by the branch protections of base_branch pass. https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue#how-merge-queues-work https://docs.github.com/en/repositories/configuring-branches... I understand not everybody uses GitHub but I'm pretty sure other providers also have similar features, e.g. https://docs.gitlab.com/ci/pipelines/merge_trains/#enforce-merge-trains https://docs.gitlab.com/ci/pipelines/merge_trains/#enforce-m... So what's different/special about Uber's thing?