Strange git-show-branch behavior.

Hello,

I need to ask about git-show-branch once again as I really can't understand its behavior myself. Could please anybody either confirm bug(s) in git-show-branch, or explain why does it work this way.

Consider its invocation in a toy repository that has total 6 commits, as can be seen from this output:

$ git branch
* master
  mybranch
$ git rev-list master mybranch --pretty=oneline
e9217caffebd6311073867d410f0c6e46910a13d Go to sleep
5f19837be87493e9b284fe7db03f00f23d006d2e Merged mybranch
2e2a4956db9737faf5f4f296b895500fafab7350 Some fun.
6478a15c48b0a7ce28069310ff5e51f95b250c7c Some work.
48d3660dc2005471c27f1d5b09d334885b612380 Commit message
2c14c05709bde3c1a7bbdd7effbf73a5667fa265 Initial commit
$

Or, using git-show-branch itself:

$ git-show-branch --more=9 master [master] Go to sleep [master^] Merged mybranch [master^^2] Some work. [master~2] Some fun. [master~3] Commit message [master~4] Initial commit $

[NOTE: the format of this output contradicts the manual page, but it's
 not the topic of this post]

Now comes the confusion:

$ 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?

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.

$ git --version git version 1.5.3.5.529.ge3d6d $

[The version is from today's master, but I tried with git version 1.5.3.4 as well, and with the same result]

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

Because you didn't pass --sparse.

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.

Björn

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

[...]

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.

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.