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

this is awesome! congrats on the launch!!

Congratulations on the launch. Great idea and definitely agree that this is a problem at a lot of companies.

Although I am curious about if there is enough market for this product. Would love to hear back any market research you guys have done before. Thanks! :)

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

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

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