Hello, tl;dr; --> Please add --no-diff (or --msg-only) to git show. We'll love you for that. :)
Expanded: (I've been a casual git user for 2-3 years; "casual" means using a small subset, nowadays daily, with some less trivial things at times, like per-commit patching for post-hoc auto-versioning, or push-deploying (the old way), so not 100% newbie; doing SW for 25+ years. I'm telling this, because I'm probably a representative sample of a huge number of experienced professionals, who are relatively new to git (compared to their age...), but already routinely use it in "survival mode", learning it gradually, on-demand.) Today I bumped into this issue, which I then tried googling for, and found it kinda' hanging: http://stackoverflow.com/questions/17226117/git-show-commit-oneline-not-showing-oneline The source of the confusion is that git show --oneline insists on showing the diff, no matter what, while the man page is misleadingly subtle on that, as illustrated best by a comment on that SO page, exactly matching my case, too: "the answer does not however explain why git show HEAD --oneline does not produce an output as stated in the documentation: <sha1> <title line> This is designed to be as compact as possible." Note: I do understand now (after 5-10 minutes of googling in vain, mucking around with git, re-reading the man page a few times, and considering the fact that a bug like that in such a feature couldn't exist for this long -- in fact, this clue helped me more than the docs + googling together), that it's indeed, not a bug, but our lack of intimate familiarity with git and the terseness/wording of the man page together cause the confusion. (BTW, just realized: on the git show man page, also the strangely implied "log of a commit" concept (i.e. in "Pretty-print the contents of the commit logs") is partly responsible for the confusion. The term "log" doesn't mean a single event-like item, but a series of entries, a running record of events. In VCS lingo the established concept is that "a log is a list of commits", and that's even the case with git, too, of course. So, readers of the git show man page will have an impedance match there, and unnecessary difficulties understanding what is actually going on. My overloaded brain, for example, apparently opted for just filtering out that part without warning, upon the first (two) reading.) Assuming that we (the SO guy + his upvoters + me) are not the only ones, I'd suggest that instead of perhaps changing the man page, there's an other easy, also backwardly compatible, and quite straightforward way to address this: actually implementing that "unexpectedly missing" feature people intuitively look for. Please note that "show" is such a profoundly generic command verb, probably also used heavily in git, especially to show commits, that it comes to mind as second nature, without thinking, as the primary (or even as "the only") choice for showing various items in various ways -- which, in fact, it already properly does, indeed. Forcing us to use a different command (git log) for a minor sub-case of the main "show me a commit" scenario (of git show), is highly unnatural. Also, --oneline (as all the other formatting options) look and feel global to the entire context (result) of the show command, so people who have not yet unlearned to expect that, will be surprised (unpleasantly). However, simply adding --no-diff to the git show command (and the man page) would help a lot. (Something like --message-only or --only-msg etc., would be more correct (than the "potentially leaky" complement), but I'm not familiar with the general use of the "only" modifier in git options and cannot comment on that, but I've certainly seen the --no-... form at least.) Thanks a lot, and have a nice next message! :) Szabolcs
