Michael McClimon <michael@xxxxxxxxxxxx> 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.
