Mike Shal <marfey@xxxxxxxxx> 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". -- 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