Elijah Newren <newren@xxxxxxxxx> writes: > However, I think Junio said that octopus merge only handles trivial > cases anyway,... "git merge -s octopus A B C" deliberately made a design decision to strongly discourage the users from creating an octopus that requires non-trivial merges. One of the reasons is because octopus merges make the history less efficient to bisect, and they are meant as a way to bind totally unrelated changes, whose order of merging into the resulting history does not matter. Yes, it is an opinionated design choice, but "git merge" is a Porcelain that can afford to be opinionated. It also means that tools other than the git-merge--octopus backend does not have to follow the design philosophy. > ... in which case an iterated "git merge --write-tree" would > actually be a sufficient solution here and we could sidestep the more > convoluted cases. But, sadly for ZheNing, that option doesn't exist > yet -- It's still under development.
