Re: Strange git-show-branch behavior.

From: Sergei Organov <osv@javad.com>
Date: Nov 8, 2007, 09:58 UTC
Message-ID: <87bqa583e9.fsf@osv.gnss.ru>
In-Reply-To: <20071103182224.GA16345@atjola.homenet>

Björn Steinbrink <B.Steinbrink@gmx.de> writes:

> On 2007.11.03 20:46:39 +0300, Sergei Organov wrote:

[...]

Show 15 quoted lines

>> $ git-show-branch --more=9 master mybranch
>> * [master] Go to sleep
>>  ! [mybranch] Some work.
>> --
>> *  [master] Go to sleep
>> *+ [mybranch] Some work.
>> *  [master~2] Some fun.
>> *+ [master~3] Commit message
>> *+ [master~4] Initial commit
>> $
>> 
>> In this output, why git doesn't show the merge commit having "Merged
>> mybranch" commit message?
>
> Because you didn't pass --sparse.

Well, therefore, provided I have the following history:

          .-F-.  mybranch
         /     \
    A---B---C---D---E  master

the 'D' merge commit is reachable only from 'master', so 'D' is not shown unless I specify --sparse, right? Rather confusing, I'd say, and the name 'sparse' for the option suggests that the output will have less revisions in the output, not more. I mean I even didn't care to look at the description of --sparse when I first read the manual page in order to find some option to increase number of revs output, while I did look at the --more.

What is the rationale for skipping such merge commits by default?

Anyway, courtesy to your explanation, I think I will be able to come with a patch for the 'Documentation/core-tutorial.txt' that seems to have wrong description for one of its examples.

Show 25 quoted lines

>> 
>> Yet another confusion: 
>> 
>> $ git-show-branch master mybranch
>> * [master] Go to sleep
>>  ! [mybranch] Some work.
>> --
>> *  [master] Go to sleep
>> *+ [mybranch] Some work.
>> $
>> 
>> Why does it stop at "Some work." commit? The manual page says: "Usually
>> the command stops output upon showing the commit that is the common
>> ancestor of all the branches.", so I'd expect it should go down to
>> "Commit message" commit that is the fork point.
>
> Common ancestor means, that the commit is reachable through all refs.
> Let's take a look at your history:
>
>          .-F-.  mybranch
>         /     \
>    A---B---C---D---E  master
>
> There you can see that mybranch can of course reach F, and that master
> can reach it, too. E -> D -> F. So the output stops at F, not at B.

You are right, this particular confusion was due to my misunderstanding of the term "common ancestor".

However, shouldn't "*the* common ancestor" in the manual be replaced by "*a* common ancestor"? I mean that according to git-merge-base, there could be multiple common ancestors even for 2 commits, so saying "*the* common ancestor" implies use of particular algorithm to select *the* common ancestor among all the possibilities, and therefore I'd expect some explanation of the algorithm being used to get *the* common ancestor.

-- 
Sergei.