Commit logs from last night
commitlogsfromlastnight.com
commitlogsfromlastnight.com
People who work with source control would do really well to watch how the kernel community approaches this. Commits add new features or fix bugs. They don't add broken crap to the mainline. You can version that if you want, but do it on your own branch and don't pollute the community's history with it.
If I'm working on code that there's even a chance someone else will touch in a professional setting (or that will be distributed, i.e. open source apps), I try to make my commit logs thorough, informative, and free of vulgarity. However, I have to admit that on personal projects or projects with friends - and sometimes employers who happen to be friends - if it's 2am and I've spent the past 3hrs fighting ridiculous bugs, they might sink to the level of "I hate IE" and "stopped the thing from doing stuff."
But I'd fight against the assumption that clarity is the same as verbosity. It's usually the reverse. And profanity is just another way to waste your S/N budget (and frankly it's an easier one to filter than a bunch of needless explanation).
Most of the time when I'm seriously reading commit logs, I'm doing some kind of regression hunting. There, I want to scan through the list for things that look like they might be related. Extra text hurts this task pretty badly.
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.
And sure, there are patches that go in with elaborate analysis in the commit log. Where those provide good information, I think they're great. Most of the time, they just amount to a BUG() trace stuffed in for no good reason and I find them to be noise.
And I don't see how git blame helps my problem. I have a regression, and an intuition of what kinds of changes might have caused it. A commit log will tell me whether a commit seems like a good candidate to inspect. Git blame just tells me who touched specific lines. If I knew the specific lines to look at, I wouldn't need to be applying intuition here, I'd just fix the bug.
Here's a 5 minute talk from this year's Rocky Mountain Ruby conference that explains why good commit messages are important:
http://confreaks.net/videos/744-rockymtnruby2011-lightning-t...
These commits aren't "funny" in the sense that they're clever, but it can be consoling to recognize the frustration that leads to such commits. I don't condone it, but I must admit there have been some late nights when the website just wouldn't stay the *@#$& up and I have done some things I'm not proud of....
http://fffff.at/googles-official-list-of-bad-words/ if you want the complete list of offenders
Checkout the other projects, including mine here: http://www.youtube.com/user/PennApps2011#p/u
that reveals this page as a way to add your repo to the logs: http://www.commitlogsfromlastnight.com/submit.php
uber commit msg: fuck