Jakub Narebski <jnareb@xxxxxxxxx> writes: > I'm just used to the way revisions are specified to other history > viewers: git-log (via git-rev-list), gitk, qgit. git-show-branch > is a bit odd man out here. "git-show-branch ref1 ref2 ref3" > is (without --more=n) like > > git rev-list ref1 ref2 ref3 --not $(git merge-base ref1 ref2 ref3) > > Which is handy for git-show-branch, but odd. I hate to sound harsh, but... Then you do not understand show-branch at all. Not having to say the "--not merge-base" part is NOT about being handy, but is the central part of what show-branch does. The command is about showing the commits that are on only some of the branches but not on others. Other commands you listed above are all based on rev-list logic of painting commits in two colors (either UNINTERESTING or ~UNINTERESTING) and being able to combine the set using "A..B", "^A B", and "A B --not C" notations all make sense. All combinations work as set operation -- start from union of commits reachable from positive (i.e. not prefixed with ^) refs, and subtract set of commits reachable from any negative ref. What show-branch does cannot be expressed with that two-color logic; it needs to use N colors for N input refs. After digging from the tips deep enough, you would find the common merge-base and after that point it is not interesting to show anything anymore, and that is how it stops output. - 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