Re: Strange git-show-branch behavior.

[Sergei Organov <osv@javad.com>]

Björn Steinbrink <B.Steinbrink@gmx.de> writes:
> On 2007.11.03 20:46:39 +0300, Sergei Organov wrote:
[...]
>> $ 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.

>> 
>> 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.