# Octopus? Really? Interesting...

2 messages from 2008-01-04 to 2008-01-04. Participants: Jon Loeliger, Junio C Hamano.
Thread: https://gitlist.dev/t/11474

## Jon Loeliger, 2008-01-04 18:28

Subject: Octopus? Really? Interesting...
Message-ID: <1199471321.3133.22.camel@ld0161-tx32>
URL: https://gitlist.dev/e/1199471321.3133.22.camel%40ld0161-tx32

```
Guys,

So, I brain-wedged a merge here just now
and was surprised to see that a simple
fetch-n-merge yielded an octopus merge.
I was expecting a fast-forward.  So I went
back and reviewed.  What actually happend
was this:

    $ git checkout master
    $ git fetch origin
    # check it out... looks great ... let's merge it
    $ git merge master origin/master
    merge performed by octopus.

Oh, yeah.  Duh.  I did name two branches.  Feh.

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?

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

Thanks,
jdl

```

## Junio C Hamano, 2008-01-04 22:42

Subject: Re: Octopus? Really? Interesting...
Message-ID: <7vhchti55a.fsf@gitster.siamese.dyndns.org>
URL: https://gitlist.dev/e/7vhchti55a.fsf%40gitster.siamese.dyndns.org
In-Reply-To: <1199471321.3133.22.camel@ld0161-tx32>

```
Jon Loeliger <jdl@freescale.com> 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 ;-)

```