Re: Question about pre-merge and git merge octopus strategy

From: Junio C Hamano <gitster@pobox.com>
Date: May 7, 2022, 18:37 UTC
Message-ID: <xmqq8rrdgpeu.fsf@gitster.g>
In-Reply-To: <CABPp-BGD3AZvXwmSHfQQ_xh_UqevH23kdBYijAWUk8GHu1q0Qw@mail.gmail.com>

Elijah Newren <newren@gmail.com> 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.