We had a massive merge at work last year where two teams diverged for months on a shared codebase. It took three people a full week to resolve everything, and the worst part was stepping on each other's conflict resolutions. Splitting the merge into independent slices that people can work on in parallel would have saved us a lot of pain. The integration branch approach where non-conflicting changes land automatically is a nice touch too.
rwmj 4 hours ago [-]
> where two teams diverged for months on a shared codebase
There's your problem. What was the reason for not merging small changes, bug fixes, refactors and such, early?
wren6991 3 hours ago [-]
Brought to you by classics like "how do I join all of these pthreads that I've detached?"
_s_a_m_ 1 hours ago [-]
Yeah, that is a terrible idea. Before you do this, you'll first do a redesign and split things up in packages that can be separately updated and installed.
locknitpicker 3 hours ago [-]
> We had a massive merge at work last year where two teams diverged for months on a shared codebase.
There is no tool in the world that can save you guys from yourselves. There is a reason why Agile methodologies put such a premium on continuous integration.
throwaway613746 2 hours ago [-]
[dead]
schusterfredl 4 days ago [-]
mergetopus is a tool that helps teams follow a structured workflow for very large merges by splitting one risky merge into parallelizable tasks:
* one integration branch for trivial/non-conflicting merge results
* optional slice branches for selected conflicted files
* original annotate/blame information is retained
iamjs 9 hours ago [-]
I have long wanted a tool to help split large diffs into smaller semantic changes. When you're working on a feature, for example, and end up refactoring along the way, you may wish to have your refactor reviewed and merged without any new functionality.
Cthulhu_ 5 hours ago [-]
That's when you should stop your work, make a new branch from main, do the refactoring and offer it separately; it's about (self) discipline in the end. You can probably also do something creative with cherry-pick and the like.
hebetude 3 hours ago [-]
It’s painful but this is the way. Especially if your team is slow at merging.
locknitpicker 9 hours ago [-]
> * one integration branch for trivial/non-conflicting merge results
Doesn't this mean the integration branch will be missing key updates, thus it's expected to be broken?
schusterfredl 6 hours ago [-]
hey, someone actually reads the docs :D
no, the integration branch is not "broken", its just not complete until all slices have been merged INTO the integration branch - after all slices have been merged, the integration branch is complete, yet has a non-optimal history (and most likely a wrong blame because of how git resolves the blame), - therefore the "kokomeco" branch is created after the slices have been merged, - there the original intended merge is done because the outcome of the conflicts is already known from the integration + slice branch merges.
Feel free to open issues/questions in the repo if you're interested, I merely stumble by ycombinator
locknitpicker 3 hours ago [-]
> no, the integration branch is not "broken", its just not complete until all slices have been merged INTO the integration branch
What do you call an incomplete branch that is missing slices?
> after all slices have been merged, the integration branch is complete, yet has a non-optimal history (and most likely a wrong blame because of how git resolves the blame)
What is the value proposition then? Broken integration branches that leave a suboptimal history? What am I missing?
> Feel free to open issues/questions in the repo if you're interested, I merely stumble by ycombinator
I don't think there is a compelling reason to use this tool. It messes commit history and leaves integration branches in a broken state? Not a great selling point. The alternative would be to sync with branches using standard flows such as rebasing and merges from base branches. You don't need a tool for that, only a hello world tutorial on Git.
swiftcoder 1 hours ago [-]
> What do you call an incomplete branch that is missing slices?
"incomplete", evidently. I don't see a real alternative here - you need some working space for an in-progress merge, and if you want to do the merge collaboratively, you'll want it on a branch. Just don't run CI on that branch till the merge is complete.
> Broken integration branches that leave a suboptimal history? What am I missing?
You appear to be missing the next step, where they use the merge resolutions from that suboptimal history to replay the original merge, giving you back nice clear history (and at this point, the integration branch can be discarded, presumably)
spectrumx 4 hours ago [-]
It's a good tool to solve a problem that, in truth, shouldn't be present at all in well-behaved engineering teams.
Rendered at 14:35:26 GMT+0000 (Coordinated Universal Time) with Vercel.
There's your problem. What was the reason for not merging small changes, bug fixes, refactors and such, early?
There is no tool in the world that can save you guys from yourselves. There is a reason why Agile methodologies put such a premium on continuous integration.
* one integration branch for trivial/non-conflicting merge results * optional slice branches for selected conflicted files * original annotate/blame information is retained
Doesn't this mean the integration branch will be missing key updates, thus it's expected to be broken?
no, the integration branch is not "broken", its just not complete until all slices have been merged INTO the integration branch - after all slices have been merged, the integration branch is complete, yet has a non-optimal history (and most likely a wrong blame because of how git resolves the blame), - therefore the "kokomeco" branch is created after the slices have been merged, - there the original intended merge is done because the outcome of the conflicts is already known from the integration + slice branch merges.
Feel free to open issues/questions in the repo if you're interested, I merely stumble by ycombinator
What do you call an incomplete branch that is missing slices?
> after all slices have been merged, the integration branch is complete, yet has a non-optimal history (and most likely a wrong blame because of how git resolves the blame)
What is the value proposition then? Broken integration branches that leave a suboptimal history? What am I missing?
> Feel free to open issues/questions in the repo if you're interested, I merely stumble by ycombinator
I don't think there is a compelling reason to use this tool. It messes commit history and leaves integration branches in a broken state? Not a great selling point. The alternative would be to sync with branches using standard flows such as rebasing and merges from base branches. You don't need a tool for that, only a hello world tutorial on Git.
"incomplete", evidently. I don't see a real alternative here - you need some working space for an in-progress merge, and if you want to do the merge collaboratively, you'll want it on a branch. Just don't run CI on that branch till the merge is complete.
> Broken integration branches that leave a suboptimal history? What am I missing?
You appear to be missing the next step, where they use the merge resolutions from that suboptimal history to replay the original merge, giving you back nice clear history (and at this point, the integration branch can be discarded, presumably)