Launch HN: MergeQueue (YC S21) – Automate rebasing and merging for your codebase

1. We focus on being "no-maintenance", since our primary value prop to customers is "you won't have to spend eng resources on merge problems any more". This means: a one-click "set and forget" install, no additional config files to maintain or DSL to learn, unlike bors.

2. We have all the security and access-control features you'd want (we're Soc2 compliant, offer on-prem etc). This is important since the product interacts with our customers' source code.

3. We offer various customizations on merge workflows to help our customers optimize the exact parameters they care about (eg: developer wait time vs CI costs vs time to identity bad PRs in a batch, optimistic merge heuristics etc)

4. We offer a whole host of useful analytics to show you merge bottlenecks. We initially just put these as a nice-to-have, but we've now got customers who use us specifically because of these analytics!

We're also constantly adding new features based on customer requests (for instance, the flaky test features we're piloting originally came from customer requests we kept hearing over and over!). Speaking of which, if there's something you'd like to see that you don't currently get from your existing system/bors, do let me know :)

https://github.com/Shopify/shipit-engine

For code, you need merge conflicts. Let me put it like this: Do concurrent edits in google docs always produce a valid and correct paragraph, with no grammatical errors, and that communicates the proper thoughts?

IMO the main reasons for source control are: - having revisions / diffs that can be reviewed by someone else - while working independently in a distributed fashion - easy way to rollback to an older revision

I'm not too familiar with CRDTs, will add more comments after reading more about it, but let's take Google docs as example here. What if we were all writing code in Google docs, how would that turn out.

Google docs do a decent job of versioning, so the last point can still be satisfied. I think with a source code styled version of Google docs, one can easily tag versions and do rollbacks. The issue happens when collaborating. Just from my experience working in spreadsheets where > 10 users are actively trying to modify, overwriting each other becomes very common. You can argue that it might make it easy to also fix this, but what about running the code locally?

One would have to still take a snapshot - hope that it actually compiles. From my personal experience, while I'm writing code, it rarely compiles in the first attempt. So then we would really have to work on snapshots where we know it compiles. At that point, you are really creating "commits" and pushing it to the remote. I am not sure if we can really completely avoid conflicts in such model.