In the linux kernel community, you'd get shot for this attitude. Now granted there are not many projects out there with this scale and complexity, but still: A one-liner commit-message for anything else than a trivial refactor is stupid. You want motivation for that change, references to bug reports and analysis of the problem (and potentially other ways to solve it and why they were rejected) in there.

And you absolutely don't want all that crap in the source code, because it routinely happens that a few lines of diff require a few paragraphs of commit message to explain why this is the right thing to do.

And browsing that massive amount of information with recursive git blame (or gitk's equivalent) and the more specialized history digging functions is easy. At least much easier than browsing through the equivalent embedded in source files, and I've seen the latter.

One thing you're right, though: Writing concise one-line summaries of a commit (which is the only thing a git shortlog shows) is a must.