Re: Octopus? Really? Interesting...

Jon Loeliger [off-list ref] writes:

Couple questions:

    Is it ever NOT the case, that if you are on one
    branch ("master") and name it as a "to be merged"
    branch along with some others, that we can simplify
    the request by noting that it is the same as the
    current "to be merged into" target branch?

Yes we can, but "filter ancestors out from the remotes"
computation does not happen before the merge strategy is chosen.

    Other than creating a log message with "merged
    by octopus", will this merge be content-identical
    to the obvious simplified merge?

I think octopus actually tries to be careful not to run the
read-tree 3-way merge when merging a true ancestor (see ll.77-87
in git-merge-octopus.sh, but see below), so the resulting tree
should be identical to "-s resolve" merge.

But that does not mean the user's wish to record such a commit
as one ancestor should not be honored, and I think there
actually is a benign bug there.  Due to the "Already up-to-date
with $SHA1" part, the codepath that says "Fast forwarding to:"
never actually triggers, so in practice we end up dropping any
true ancestor from the parent list of the resulting merge.  That
contradicts the comment in ll.77-87 that suggests we try not to
outsmart the user who told us to create such an octopus for
unfathomable reason ;-)