Björn Steinbrink <B.Steinbrink@xxxxxx> 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.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
