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