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

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

[Bradley Wagner]

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?

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

[Shawn O. Pearce]

Bradley Wagner <bradley.wagner@hannonhill.com> wrote:
> 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?

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`.
 
> Does git log show the parents in their ordinal order in the "Merge:" line?

Yes.

-- 
Shawn.

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

[Sverre Rabbelier]

Heya,

On Wed, Jul 28, 2010 at 21:19, Shawn O. Pearce <spearce@spearce.org> 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`.

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

-- 
Cheers,

Sverre Rabbelier

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

[Bradley Wagner]

On Thu, Jul 29, 2010 at 1:55 PM, Sverre Rabbelier <srabbelier@gmail.com> wrote:
>
> Heya,
>
> On Wed, Jul 28, 2010 at 21:19, Shawn O. Pearce <spearce@spearce.org> 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`.
>
> Do we have an explanation anywhere as to when one would use a octopus merge?

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.

>
> --
> Cheers,
>
> Sverre Rabbelier

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

[Joshua Juran]

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

> Heya,
>
> On Wed, Jul 28, 2010 at 21:19, Shawn O. Pearce <spearce@spearce.org>  
> 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`.
>
> Do we have an explanation anywhere as to when one would use a  
> octopus merge?

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

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

[Sverre Rabbelier]

Heya,

On Thu, Jul 29, 2010 at 13:10, Joshua Juran <jjuran@gmail.com> 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

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

-- 
Cheers,

Sverre Rabbelier

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

[Junio C Hamano]

Sverre Rabbelier <srabbelier@gmail.com> writes:

> Heya,
>
> On Thu, Jul 29, 2010 at 13:10, Joshua Juran <jjuran@gmail.com> 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
>
> Very nice example, but do we have it _documented_ anywhere? If not, it
> would be great if you could add that somewhere :)

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.

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

[Sverre Rabbelier]

Heya,

On Thu, Jul 29, 2010 at 15:12, Junio C Hamano <gitster@pobox.com> wrote:
> 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.

Ok, do we have _that_ documented anywhere?

-- 
Cheers,

Sverre Rabbelier

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

[Junio C Hamano]

Sverre Rabbelier <srabbelier@gmail.com> writes:

> On Thu, Jul 29, 2010 at 15:12, Junio C Hamano <gitster@pobox.com> wrote:
>> 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.
>
> Ok, do we have _that_ documented anywhere?

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