Re: git show-branch --topics and merge commits

Mike Shal [off-list ref] writes:

Ok, makes sense. Is 'git rev-list' supposed to give the same list of
commits then? In my example, rev-list shows the commit on the branch
even after upstream has been merged in.

"show-branch" was designed to stop after seeing a commit that are shared
with all the branches it was given, so

	git show-branch A B

is more like

	git rev-list --left-right --boundary A...B

and not at all like

	git rev-list A..B

which is to show all commits not in A that appear in B.

Note that show-branch was invented way before the log family of commands
(which rev-list is a member of) learned --left-right/--boundary/--graph
options, and I personally think its graphical output mode outlived its
usefulness as a stopgap measure.  As its "merge-base" and "independent"
modes have also been made redundant (see "git merge-base" for two options
to mimic their behaviour), we may want to start thinking about deprecating
the command, and the first step perhaps would be to replace its mention
from the first part of the Everyday Git document with something more
appropriate such as "git log".

On Mon, Jul 18, 2011 at 2:14 PM, Junio C Hamano [off-list ref] wrote:

Note that show-branch was invented way before the log family of commands
(which rev-list is a member of) learned --left-right/--boundary/--graph
options, and I personally think its graphical output mode outlived its
usefulness as a stopgap measure.  As its "merge-base" and "independent"
modes have also been made redundant (see "git merge-base" for two options
to mimic their behaviour), we may want to start thinking about deprecating
the command, and the first step perhaps would be to replace its mention
from the first part of the Everyday Git document with something more
appropriate such as "git log".

Hmm I had no idea 'git log' was so powerful. I'll be using that from
now on instead of show-branch --topics :)

Thanks for your detailed response,
-Mike