A Git helper tool that breaks large merges into parallelizable tasks (github.com)
34 points by schusterfredl 4 days ago
redoh 12 minutes ago
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.
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 5 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_ 9 minutes 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.
locknitpicker 4 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 an hour 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