What is the scenario for a commit with 3 or more parents

I was reading over the Specifying Revisions section in the man entry gitrevisions. I understand having 2 parent commits with a merge.

I was trying to understand the HEAD^2 style syntax and wondering where HEAD^3 would be used. From the example diagram, this would be Commit B but I'm unclear how this would ever happen. Is this some kind of multi-way merge?

Does git log show the parents in their ordinal order in the "Merge:" line?

Bradley Wagner <bradley.wagner@hannonhill.com> wrote:

Yes.  Its called an octopus merge.  It happpens sometimes when
merging 2 or more otherwise fairly isolated changes in a single
shot.  E.g. `git merge feature-a feature-b thing-c`.
 

Yes.

Heya,

On Wed, Jul 28, 2010 at 21:19, Shawn O. Pearce <spearce@spearce.org> wrote:

Do we have an explanation anywhere as to when one would use a octopus merge?

On Thu, Jul 29, 2010 at 1:55 PM, Sverre Rabbelier <srabbelier@gmail.com> wrote:

Another question I had about this: isn't this documentation about "multi-way merge" inaccurate: http://book.git-scm.com/5_advanced_branching_and_merging.html.

Sounds like it's not equivalent to merging each branch individually.

On Jul 29, 2010, at 10:55 AM, Sverre Rabbelier wrote:

How about if you had two (or more) components with a shared protocol, and you updated each to speak a new (and incompatible) protocol. The changes to each component might be done in separate topic branches, but you'd want to merge them all at once.

$ git checkout master $ git merge client-v2 server-v2

Josh

Heya,

On Thu, Jul 29, 2010 at 13:10, Joshua Juran <jjuran@gmail.com> wrote:

Very nice example, but do we have it _documented_ anywhere? If not, it would be great if you could add that somewhere :)

Sverre Rabbelier <srabbelier@gmail.com> writes:

Please don't.

I actually do not think the "client-server" is a good example from software engineering point-of-view, as it means that everybody talks version 1 before that merge and everybody talks version 2 after that merge, i.e. you have a flag day event.

Think for 5 seconds how one would have tested client-v2 topic alone in isolation.

The only transition plan that works in real life is for the updated client to talk fine with a server without version 2 support, while being prepared to talk the newer protocol if the server supports it. The server side needs to be arranged in a similar way.

If that is how these topics were developed, you should be able to merge client-v2 topic and then server-v2 topic, or in the other order, without breaking anything on the master branch.

The original idea of Octopus was that, when

 (1) you have many topics that are not inter-related; _and_

 (2) merging all of them in any random order wouldn't have made any
     difference in the resulting history, either in the end result nor in
     any of the intermediate steps,

it is not worth to serialize the merge order and create extra merge commits.

I think we tend to discourage the use of Octopus these days, as people are fallible. When topics that they originally thought are independent turn out to have funny interactions among each other, having an Octopus merge across them tends to make bisection much less efficient in order to find the real culprit in the history when you find something is broken.

Compared to that downside, it is not worth to use an Octopus, only to have a smaller number of merge commits and a cool-looking lantern-shaped merge commit in the history.

Heya,

On Thu, Jul 29, 2010 at 15:12, Junio C Hamano <gitster@pobox.com> wrote:

Ok, do we have _that_ documented anywhere?

Sverre Rabbelier <srabbelier@gmail.com> writes:

Outside the list archive, I don't think so.