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

Thanks @timtamboy63, now we know you you are :)

Thanks for asking! We priced it to ensure that it's affordable for small teams and is only charging based on who uses it for larger teams. Would you have preferred a different plan.

tbh we've found it's just easier for many of our customers that way. However, we do offer custom pricing plans (annual contracts etc), so do let us know if you have a different preference!

<3 Let us know what you think!

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.

Thanks for the support!!

Because you'd never have a working revision to release, since everyone on the team will not finish their features at the same time.

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?

    if(foo()) {
      send_money_to_oftenwrong()
    }

    if(bar()) {
      send_money_to_oftenwrong()
    }

    if(baz()) {
      send_money_to_oftenwrong()
    }

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.

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.

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...

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.

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" .... ;-)

> why isn't the ideal interface for developing in teams something more like editing in Google docs

Engineering and debugging are hard enough as it is. Doing this while one or more people are changing the code in real time would be a nightmare.

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

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

Yes it's somewhat similar to GitLab merge train. Of course we work with Github. And similar to other comments, there are a few more features including batch mode and flaky test management that make MQ a more interesting offering. We do not support Gitlab today.

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.

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".

Wow this is amazing. May be you should add MergeQueue to your list :)

- Yeh we define our own pre-conditions because some developers also use it for non-protected branches. The default picks up the Github build-in preconditions and allows you overwrite. - Can you clarify your fixup commit suggestion? So there's typically an option to squash and merge when merging the PR, but sounds like you want to maintain some of those commits and squash the rest? - Just read up the AzDO's semi-linear rebase.Yeh MQ should be able to do that as well. You can specify different config for rebasing the branch and for merging the PR.

Curious since you have done this much research - have you built or used any of the merge queues in your company? Would love to chat more. ankit[at]mergequeue[dot]com

Are you worried about market size of developer productivity tools in general or just about MQ? We intend to expand into other dev productivity capabilities adjacent to MQ. Our exploration into Flaky test management is also a step in that direction.

That's a great question. FWIW Gitlab does have merge train with similar baseline functionality. There's two part answer to your question: - even though it's trivial from the face of it, since we specialize in merging process, we are able to provide much more complex workflows, such as batch mode. - starting with MQ, our goal is continue focusing in engineering productivity and build as we understand the use cases better. We imagine a world where every team has the toolset that is built internally by developer productivity teams at the likes of Google, FB. We have to still start somewhere right :)

That's the world I'm hoping for, as well. I'm the lead contributor to bors-ng.

Like Steve Jobs criticizing Dropbox, I think that bors is a feature, not a product. If GitHub integrated merge trains, I would probably just call it quits and put bors-ng on feature freeze, maintaining it only enough to make sure it stays working and patched for vulnerabilities while everybody migrates off of it.

There are a few reasons for this, but mostly it's because of all the unfixable bugs and limitations that are caused because bors-ng isn't a GitHub feature.

* I can't squash PRs while still having them show up as purple in the GitHub UI. GitHub just doesn't let you do that.

* The CI configuration needs to be partially duplicated between the CI system itself and bors.toml. To fix this, bors would need to implement its own GitHub Actions workflow file parser. If implementing the CODEOWNERS file is any indication, that basically means reverse-engineering GitHub's behavior, because you can bet your life their documentation won't cover every possible corner case.

* Some pull request review features need to be duplicated between GitHub itself and bors-ng, like pre-checks and CODEOWNERS, because there's no stable API to get that information.

* Bors-ng isn't allowed to modify GitHub Workflow files [1]. They just don't let GitHub Apps do that.

* Bors-ng can't always tell whether a CI error should cause the PR to be rejected, or if it's just going to be retried later [2]. To fix this, it basically need to know incident information for the CI provider, which basically means it would have to have a hotline to their ops teams, which I don't.

[1]: This is because bors-ng is an app, rather than a machine user. It would be fixable, but fixing it would make it harder to deploy.

[2]: https://twitter.com/AstraLuma/status/1300797343135137796

These are the biggest problems I have with bors-ng right now. Some of these are theoretically solveable, if you're willing to do way more work than I am, but some of them are truly impossible for anyone but GitHub to solve, and all of them are easier for GitHub to solve than they are for anyone else because they have infrastructure powers that we don't have.

It's honestly a little demoralizing.