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 4 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.
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 47 minutes 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
Rendered at 09:28:41 GMT+0000 (Coordinated Universal Time) with Vercel.
* 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