alt Hacker NewsI'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...
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-m...
So what's different/special about Uber's thing?
Replies
I was long before github made it. Otherwise thing is similar from usage perspective
I think it's much cleverer about the order in which it tries to merge PRs, and how they are grouped.
GitHub merge queues just do it in the order you click.
Also I'm pretty sure it predates GitHub's implementation by a fair bit. Uber were one of the first people to do this. Maybe the first IIRC.
I've been doing this for years (8+ at most recent place?) and we did it about 15years ago at place before. We keep having to relearn these features, which is on eof the reasons why some groups are far more effective than others