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

Feels like this should be a post in itself! This is just my opinion so open to any push backs / comments.

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.

On the contrary, I for one am amazed how often no intervention is necessary on automatic merges, given how finnicky compilers are in general! If the teams are not ridiculously large and people mostly work on their own stuff and coordinate work on the "common" part, isn't it mostly good?

There are certainly usability issues with git but I wouldn't literally use Google docs with colored squiggly lines for the changes from Anne and Bob...

It’s a good question. Well, CRDTs are just an underlying data type that guarantee conflict free eventual consistency. That doesn’t mean the result would be an English paragraph or buildable code, however. Then what git does really well that bare CRDTs don’t are things like branching and local experimentation. Being intentional with commit points can also keep file sizes down, for a more real-time tool like Docs potentially every character change would be stored. CRDTs can have performance problems with things like file size growth.

For, your use case of user changes, CRDTs seem like a good option. It would be interesting to explore building a version control system on top of CRDTs, if done right it could have the benefits of git with less merge conflicts.

For user changes, a solution based on OT/CRDT may be appropriate.

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?

Wow, that's a great story, maybe we should quote that :) If you are open to sharing more of that experience, I would love to hear that. You can also directly email me at ankit[at]mergequeue[dot]com if you don't want to post publicly.

bors solves a similar problem, but we've found that enterprises require a lot of additional features to get their dev teams to actually use it, so we've focused on those to make this production-ready. Specifically:

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 :)

This was my question too. I considered making a company out of Bors but didn’t think it would work because Bors mostly just works.

<3 curious where have you experience this the most? We are also trying to figure out at what point does the problem become acute.

similar to how we compare with bors, actually! https://news.ycombinator.com/item?id=27858794

tl;dr: Our goal is to be the absolute lowest-maintenance option for your team :)

Fair point! We definitely don't want our analytics to be used to enforce/incentivize arbitrary targets (we've seen those behaviors backfire so many times, unfortunately...). I'll update the language from "Keep a tab on your builds and merges. Know your star developers" to "Keep tabs on your builds, merges and developer activity".