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.

In real time collaboration, like Google docs, merge conflicts can be avoided because you see them play out live, and can react to them.

In an offline collaboration system merge conflicts are a feature, they bring attention to inconsistencies you might otherwise overlook.

This has very little to do with how the data is stored.

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.

Fork => Modify => Merge.

Suppose you have a 100 page gdoc. You start editing one paragraph per page, and voila, everything is fine. Casual edits are consistent "in context".

However, if you start editing on page 1, then skip to page 100 and go back to page 50, then it's possible that while "there was no conflict" (people weren't editing the same section of the doc at the same time), however, the document was in a "semantically inconsistent state" while you were making your edits (ie: someone trying to "compile" your doc in between the beginning and conclusion of your changes would have had a logic error until you'd made that final edit).

Git (and branching, as you're suggesting) allows you to select the next "actual" future from many "plausible" futures.

Think of A.C.I.D. You want your changes to be atomic (gdoc edits are not atomic across multiple "pages"), you want your changes to be durable (gdocs may/may not hit your definition for durability if changes can be made to the lines arbitrarily), consistency and isolation are also compromised with the free-flowing editing style you're describing.

Imagine dumping a python script into gdocs, pulling down the contents, and running it through a local python interpreter.

You could get pretty far with low amounts of edits and using the "comment" feature liberally, but once you try and "propose a refactor" you immediately need to "fork the universe" and have two (or more) semantically distinct representations of the document, or some way of queuing "multi-page edits" such that each could come in ... some sort of "merge queue" .... ;-)

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.

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.

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