Swearing doesn't bother me, but lack of content does. Commit logs help you find things later and help you communicate what happened without the other person looking at the diff directly. Consider the difference between "fuck yeah dawg" and "fuck yeah, got the XYZ widget prototype working". </buzzkill>
Even the latter is pretty awful. "Got XYZ working" tells you nothing about the bug that was fixed, nor why the broken feature was in the branch in the first place.
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.
Was going to post the same thing. These are the comments that piss the hell out of you two months later when your live in production and need to fix a issue related to cs XXXX with description ("I finally f_cking got this working, what a hack") with out having any idea of what exactly was hack,and what exactly was fix and which of the changes can actually be safely updated.
I certainly agree, but I think we've probably all been there.
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."
Those examples aren't awful, actually. A one-liner commit log is the ideal, not a huge paragraph of description (if that's really needed, it should be in the comments, not the metadata). Maybe "I hate IE because I can't use X" would be better, and "stopped the thing from doing XYZ" would add more info.
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.
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.
The kernel folks shoot people regularly for far milder offenses, so that's not really surprising. That said, I don't think we're reading commit logs for the same kernel. I see two-liners routinely in the log (because checkpatch wants the shortlog and a body -- but note that these are often just rephrasings of each other). And the kernel workflow encourages batching up what would otherwise be many small changes into well-formed patch sets, which means that you get a coarser granulatiry of changes than many projects.
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.
This isn't so much a celebration as a public shaming. We all know you're not supposed to be "that guy", right?
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....
To be fair, I don't the the point of Texts From Last Night (which this is a parody of/homage to) is "celebrating" ill-considered drunken text messages. For whatever reason, humans find it entertaining to watch other humans do stupid things.
I developed it at PennApps a couple weeks ago. I'll be adding GitHub authentication soon, so you can add all your logs to the site. Was kind of hoping it didn't make HN until then :)
It seems to be late commits on public githubs account. Maybe filtered by curse word.
The default picture on the avatars seems to be the little cute octopus thing of github.
Maybe combine this with LOC to find swears per line, or include the language for find which ones cause the most swears. Maybe leaderboards too (like CurseBird) to find the sweariest projects & developers.
As the non-technical co-founder of a tech startup, commit comments are consistently the most enjoyable part of my job. Reading things like "tell me your secrets!" or "I think I destroyed the entire database" followed by "nope, still there" always make me laugh.
