Re: Potential bug with octopus merges and symlinks

[Junio C Hamano <gitster@pobox.com>]

Michael McClimon <michael@mcclimon.org> writes:

> The order here matters! Here is every permutation (1 here is the symlink
> change) to git merge; only the first two fail, all the others work.

I am not an active Octopus contributor, but was the original
inventor.  And it is not surprising that the order matters, because
I designed it that way ;-)

In the original design, octopus was to be used only to create the
simplest forms of merges without any conflicts, because octopus
merges make it almost impossible to examine the result of the merge
with comparison between one of the parent and the result (you have
to remember that there was no "diff --cc" invented yet, let alone
"diff --remerge-diff", back then to help us).  Aborting the merge at
the first conflict when merging the remote heads one by one is a way
to make sure that the result is a simple "combine unrelated work
into one" merge.  This does make the order matter somewhat.  When
more than one remote heads touch the same path, the order in which
they are merged into base does make a difference.

To be more strict for the goal of limiting octopus to the simplest
forms of merges without any conflicts, we should have insisted that
the set of paths these remote heads want to modify should not
overlap and that would have made the order totally not to matter,
but "abort at the first conflict" was easier to implement and
practical.

And later, before the command got part of the git suite, the rule
was further loosened to allow a conflicting merge when merging the
last remote head and let the user hand-resolve.  This makes the
order matter even more.