Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

21–30 of 59 posts

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

#21

Post by eatonphil »

oftenwrong wrote: post #17
eatonphil wrote: post #14

Really dumb question while I'm trying to decide whether to use something like git vs. CRDTs to handle version control for user changes made in an app I'm working on: why do we even use git anymore for source code version control if we want behavior like this? Nobody likes merge conflicts. We all want versioning. So long as we have versions at all why isn't the ideal interface for developing in teams something more li…

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 we need merge conflicts that must be manually resolved, how can this product being discussed exist?

If merge conflicts can be automatically resolved, why aren't we using a system that does operates like that under the hood rather than needing a product like this bolted on?

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

#24

Post by ankitdce »

eatonphil wrote: post #21
oftenwrong wrote: post #17

Earlier quoted context omitted.

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 we need merge conflicts that must be manually resolved, how can this product being discussed exist? If merge conflicts can be automatically resolved, why aren't we using a system that does operates like that under the hood rather than needing a product like this bolted on?

The product being discussed here doesn't solve the issue of merge conflicts itself, but rather of eventual consistency. Merge conflicts is only a part of it, and there are some heuristics that can be used to reduce those, but eventually require manual review. Perhaps with Github Copilot this can improve?

An example of the problem we are describing is explained here: https://blog.mergequeue.com/managing-github-merges-for-high-...

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

#25

Post by lifekaizen »

eatonphil wrote: post #14

Really dumb question while I'm trying to decide whether to use something like git vs. CRDTs to handle version control for user changes made in an app I'm working on: why do we even use git anymore for source code version control if we want behavior like this? Nobody likes merge conflicts. We all want versioning. So long as we have versions at all why isn't the ideal interface for developing in teams something more li…

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.

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

#26

Post by ankitdce »

oracle2025 wrote: post #22

Can say from my professional experience, that this is definitely a problem worth solving.

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

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

#27

Post by jeremyis »

A previous employer that underwent a massive multi-billon dollar migration to SOA (and then folks went too far and made everything a micro-service so had to rollup some work) basically because merging became too slow into our monorail as we got to ~O(1k) engineers. We had an in-house solution like this that we used for 2-3 years (and a worse version for years before that). What a great idea to productive it!

IMO the SOA migration simply due to merging was such a heavy-handed solution. If we could have made our MergeQueue way better, perhaps we could have avoided that multi-billion dollar (+ the rollback work) fiasco.

Congrats!

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

#28

Post by sdesol »

I'm not your competitor, but I am trying to make software metrics a good thing for everybody (developers and leaders) and I'm not sure you can make a claim like the following on your landing page:

   "Know your star developers."
with the limited analytics that you can gather from a pull request.

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

#29

Post by programmarchy »

ankitdce wrote: post #26
oracle2025 wrote: post #22

Can say from my professional experience, that this is definitely a problem worth solving.

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

Here’s one. I currently have about five or six small PRs open for bug fixes and minor features. However, they’ve languished a bit in review and haven’t been merged yet. In the meantime, I’ve started a fairly significant refactor. It’s not too complicated but involves moving files and changing some core structures. I am dreading having to rebase those open PRs!

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

#30

Post by oftenwrong »

eatonphil wrote: post #21
oftenwrong wrote: post #17

Earlier quoted context omitted.

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 we need merge conflicts that must be manually resolved, how can this product being discussed exist? If merge conflicts can be automatically resolved, why aren't we using a system that does operates like that under the hood rather than needing a product like this bolted on?

There are ways to resolve merge conflicts automatically in some cases given some assumptions, but there is no way to resolve any given merge conflict without a system that can create a correct program. I won't bore you with the formal proof for this (especially since I have no idea how to construct such a proof). Consider that some merge conflicts require new code to be written to resolve them.

For example, here's an original program:

    if(foo()) {
      send_money_to_oftenwrong()
    }
and here's a change we would like to merge:

    if(bar()) {
      send_money_to_oftenwrong()
    }
and here's a concurrent change we would like to merge:

    if(baz()) {
      send_money_to_oftenwrong()
    }
How do you produce the correct program from these conflicting changes?

---

Also for example, an unsophisticated and unsound method for automatically resolving some merge conflicts:

1. Assume that if the build and tests succeed, the program is correct. (This is the most important bit)

2. Accept all non-conflicting changes.

3. For conflicting changes, accept one side of the conflict.

4. Build and test the result. If it succeeds, merge it.

5. Otherwise, attempt the same with the other side of the conflict. If it succeeds, merge it.

6. Otherwise, it cannot be merged automatically by this method.

Note that this approach could also apply to a CRDT-based merge.

Post reply on HN