alt Hacker Newshey, 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
> 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.