From: Sergei Organov <osv@javad•com>
To: "Björn Steinbrink" <B.Steinbrink@gmx•de>
Cc: git@vger•kernel.org
Subject: Re: Strange git-show-branch behavior.
Date: Thu, 08 Nov 2007 12:58:38 +0300 [thread overview]
Message-ID: <87bqa583e9.fsf@osv.gnss.ru> (raw)
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:
[...]
>> $ 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.
prev parent reply other threads:[~2007-11-08 9:59 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-03 17:46 Strange git-show-branch behavior Sergei Organov
2007-11-03 18:22 ` Björn Steinbrink
2007-11-08 9:58 ` Sergei Organov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87bqa583e9.fsf@osv.gnss.ru \
--to=osv@javad$(echo .)com \
--cc=B.Steinbrink@gmx$(echo .)de \
--cc=git@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox