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.

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