<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>eatonphil</author><text>Really dumb question while I&amp;#x27;m trying to decide whether to use something like git vs. CRDTs to handle version control for user changes made in an app I&amp;#x27;m working on: why do we even use git anymore for source code version control if we want behavior like this?&lt;p&gt;Nobody likes merge conflicts. We all want versioning. So long as we have versions at all why isn&amp;#x27;t the ideal interface for developing in teams something more like editing in Google docs? Why aren&amp;#x27;t we just doing that? Why are we still using systems that produce merge conflicts?&lt;p&gt;Hoping for insight from folks who have either done this themselves or looked into it.&lt;p&gt;Edit: one particularly nice feature of Google docs over Confluence is that in Google docs I can suggest changes that is somewhat akin to branches with git. I don&amp;#x27;t need to force my change through without review. This isn&amp;#x27;t a natural part of CRDTs, but it sounds like the nicest source control system might be CRDTs plus branches?</text><parent_chain></parent_chain></comment><story><title>Launch HN: MergeQueue (YC S21) – Automate rebasing and merging for your codebase</title><text>Hi HN, we’re Spriha and Ankit, founders of MergeQueue (&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;mergequeue.com&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;mergequeue.com&amp;#x2F;&lt;/a&gt;). We enable automatic merges for your Github Pull Requests, based on configurable rules you can set for each repo. These automated merges ensure you never have failing builds on master&amp;#x2F;main and save time on rebasing your feature branches.&lt;p&gt;If you have a monorepo where a big engineering team is regularly merging changes, the stability of the main branch degrades considerably. This happens because more engineers working on the same codebase introduce incompatible changes, causing builds to break even though their commits pass independently. Here’s an example: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;blog.mergequeue.com&amp;#x2F;managing-github-merges-for-high-output-engineering&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;blog.mergequeue.com&amp;#x2F;managing-github-merges-for-high-...&lt;/a&gt;.&lt;p&gt;Github has a setting to restrict branches to be up to date before merging, but turning on that setting ends up forcing a rebase-athon within the team. This results in wasted time, and all too often, a stressful scramble to figure out what changes broke the build.&lt;p&gt;We had this problem in our previous company where we looked for a solution to automate the process. We found this paper [1] published by Uber to manage monorepos at scale and we built a lightweight version of that internally. It immediately eliminated the overhead of keeping builds healthy. After that, we decided to build a public version to save others from re-inventing the wheel.&lt;p&gt;We spoke to engineers at Airbnb, Stripe, Uber, Shopify, Quora and other large companies who have internally built similar tools, but teams who need such tools the most often don’t have the bandwidth to dedicate developers to building and maintaining them.&lt;p&gt;MergeQueue (MQ) is a FIFO queue of Pull Requests (PRs) that works as a Github app. To use MQ as a developer, instead of merging manually, you just add a Github Label “mergequeue” to the PR. MQ then takes care of the rest: it sequentially updates or rebases the branch, monitors the configured CI checks and eventually merges the changes. If the checks fail, it will dequeue the PR, add comments describing the reason and move to the next one. For high output teams, MQ also offers batch mode to run CI in parallel batches.
If you’d like to learn more, there’s a lot more here: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;mergequeue.com&amp;#x2F;documentation&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;mergequeue.com&amp;#x2F;documentation&lt;/a&gt;.&lt;p&gt;Currently, we are also piloting a way to manage “flaky” (i.e. unreliable) tests through MQ. This integrates with your CI provider (we currently support CircleCI), analyses test results and flags the tests that fail inconsistently. When flaky tests are identified, MQ reruns the test depending on the configuration set.&lt;p&gt;We charge by usage in an organization, so for instance if your organization has 100 developers but only 20 of them use MQ, only those 20 will be billed. You can sign up for a free 14 day trial without a credit card. We also support single tenant or on-prem deployments, have webhooks to connect to your other apps, offer multi-queue support, and are SOC2 certified!&lt;p&gt;We’d love for you to try MergeQueue and give us any feedback you have. If you&amp;#x27;ve used something similar in the past, we&amp;#x27;re also curious to learn what problems you faced so we&amp;#x27;re better prepared for them ourselves :)&lt;p&gt;[1] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;eng.uber.com&amp;#x2F;research&amp;#x2F;keeping-master-green-at-scale&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;eng.uber.com&amp;#x2F;research&amp;#x2F;keeping-master-green-at-scale&amp;#x2F;&lt;/a&gt; - discussed at the time: &lt;i&gt;Keeping master green at scale&lt;/i&gt; - &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=19692820&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=19692820&lt;/a&gt; - April 2019 (115 comments)</text></story>
<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>h3mb3</author><text>How does this compare to Bors NG?&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;bors-ng&amp;#x2F;bors-ng&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;bors-ng&amp;#x2F;bors-ng&lt;/a&gt;</text><parent_chain></parent_chain></comment><story><title>Launch HN: MergeQueue (YC S21) – Automate rebasing and merging for your codebase</title><text>Hi HN, we’re Spriha and Ankit, founders of MergeQueue (&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;mergequeue.com&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;mergequeue.com&amp;#x2F;&lt;/a&gt;). We enable automatic merges for your Github Pull Requests, based on configurable rules you can set for each repo. These automated merges ensure you never have failing builds on master&amp;#x2F;main and save time on rebasing your feature branches.&lt;p&gt;If you have a monorepo where a big engineering team is regularly merging changes, the stability of the main branch degrades considerably. This happens because more engineers working on the same codebase introduce incompatible changes, causing builds to break even though their commits pass independently. Here’s an example: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;blog.mergequeue.com&amp;#x2F;managing-github-merges-for-high-output-engineering&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;blog.mergequeue.com&amp;#x2F;managing-github-merges-for-high-...&lt;/a&gt;.&lt;p&gt;Github has a setting to restrict branches to be up to date before merging, but turning on that setting ends up forcing a rebase-athon within the team. This results in wasted time, and all too often, a stressful scramble to figure out what changes broke the build.&lt;p&gt;We had this problem in our previous company where we looked for a solution to automate the process. We found this paper [1] published by Uber to manage monorepos at scale and we built a lightweight version of that internally. It immediately eliminated the overhead of keeping builds healthy. After that, we decided to build a public version to save others from re-inventing the wheel.&lt;p&gt;We spoke to engineers at Airbnb, Stripe, Uber, Shopify, Quora and other large companies who have internally built similar tools, but teams who need such tools the most often don’t have the bandwidth to dedicate developers to building and maintaining them.&lt;p&gt;MergeQueue (MQ) is a FIFO queue of Pull Requests (PRs) that works as a Github app. To use MQ as a developer, instead of merging manually, you just add a Github Label “mergequeue” to the PR. MQ then takes care of the rest: it sequentially updates or rebases the branch, monitors the configured CI checks and eventually merges the changes. If the checks fail, it will dequeue the PR, add comments describing the reason and move to the next one. For high output teams, MQ also offers batch mode to run CI in parallel batches.
If you’d like to learn more, there’s a lot more here: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;mergequeue.com&amp;#x2F;documentation&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;mergequeue.com&amp;#x2F;documentation&lt;/a&gt;.&lt;p&gt;Currently, we are also piloting a way to manage “flaky” (i.e. unreliable) tests through MQ. This integrates with your CI provider (we currently support CircleCI), analyses test results and flags the tests that fail inconsistently. When flaky tests are identified, MQ reruns the test depending on the configuration set.&lt;p&gt;We charge by usage in an organization, so for instance if your organization has 100 developers but only 20 of them use MQ, only those 20 will be billed. You can sign up for a free 14 day trial without a credit card. We also support single tenant or on-prem deployments, have webhooks to connect to your other apps, offer multi-queue support, and are SOC2 certified!&lt;p&gt;We’d love for you to try MergeQueue and give us any feedback you have. If you&amp;#x27;ve used something similar in the past, we&amp;#x27;re also curious to learn what problems you faced so we&amp;#x27;re better prepared for them ourselves :)&lt;p&gt;[1] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;eng.uber.com&amp;#x2F;research&amp;#x2F;keeping-master-green-at-scale&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;eng.uber.com&amp;#x2F;research&amp;#x2F;keeping-master-green-at-scale&amp;#x2F;&lt;/a&gt; - discussed at the time: &lt;i&gt;Keeping master green at scale&lt;/i&gt; - &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=19692820&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=19692820&lt;/a&gt; - April 2019 (115 comments)</text></story>