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

31–40 of 59 posts

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

#31

Post by spriha »

sdesol wrote: post #28

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.

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

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

#34

Post by ankitdce »

polskibus wrote: post #23

How does it compare to GitLab's merge train feature?

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.

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

#35

Post by ankitdce »

jeremyis wrote: post #27

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…

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.

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

#36

Post by UweSchmidt »

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…

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

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

#37

Post by eatonphil »

UweSchmidt wrote: post #36
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…

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 f…

I don't mean literally Google docs but a storage system more like that than git. :)

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

#38

Post by spriha »

rokob wrote: post #33
h3mb3 wrote: post #10

How does this compare to Bors NG? https://github.com/bors-ng/bors-ng

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.

Haha yeah we're that company- turns out there's actually a lot to do, especially when handling this at scale! come join us :)

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

#39

Post by ankitdce »

programmarchy wrote: post #29
ankitdce wrote: post #26

Earlier quoted context omitted.

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

Interesting, you can potentially use MQ for automatic rebasing as well, but if there is a merge conflict, MQ will not be able to resolve it for you. If a rebase can be automatically resolved, then MQ will update the branch for you.

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

#40

Post by ItsMonkk »

oftenwrong wrote: post #30
eatonphil wrote: post #21

Earlier quoted context omitted.

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…

I'm on a medium sized team so this might not be possible for everyone. The way I resolve this in my Trunk-Based source control system(so we heavily use Feature Flags) is to just never merge.

Every person who is to check-in code is to first stash their changes, pull all code, then pop the stash and deal with any conflicts locally, do the relevant testing, then check-in. The entire repo is checkin 1 -> checkin 2 -> checkin 3 -> etc..

When viewed in this light it is no different than if you had pulled the baz() code before you started editing anything. Would you have changed it to bar() or not?

Post reply on HN