Commit logs from last night(commitlogsfromlastnight.com)
commitlogsfromlastnight.com
Commit logs from last night
http://www.commitlogsfromlastnight.com/
13 comments
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.
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.
I agree with you, but at least it's something. We try to couple things with bugs as much as possible (and are never moved to swear).
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.
Come on, this is a play on "texts from last night" (representative quote: "I drank entirely too much. My skin hurts to wear"). It's not life advice.
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."
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.
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.
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.
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.
I agree commit Logs are extremely useful when they tell you what was it purpose. this kind of commit logs are useless for history tracking.
Why are we celebrating irresponsible commit messages? Are people finding these to be that funny in the first place?
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...
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...
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....
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 :)
Whoops. Sorry ;)
This is funny, but I'm missing a whole lot of context. Anyone want to fill me (us?) in? :)
It's a play on Texts from Last Night, another site with regrettable communications. Every post on TFLN has comments alleging that it's fake. ;)
This was made by Abe Stanway at the most recent Penn Apps hackathon. You can see a video of his presentation here: http://www.youtube.com/watch?v=DLIf9dyxMxY
Checkout the other projects, including mine here: http://www.youtube.com/user/PennApps2011#p/u
Checkout the other projects, including mine here: http://www.youtube.com/user/PennApps2011#p/u
yes please. me too.
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.
It makes a call to this thing: http://www.wdyl.com/profanity?q=interesting
http://fffff.at/googles-official-list-of-bad-words/ if you want the complete list of offenders
http://fffff.at/googles-official-list-of-bad-words/ if you want the complete list of offenders
Other filter words appear to be 'wow' and 'balls'
managed to find this: https://github.com/astanway/Commit-Logs-From-Last-Night
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.
In a similar (but context-free) vein: http://whatthecommit.com/
Is there a way to submit logs (like how texts from last night does it)? There are a lot of amusing 4-am svn commit messages in my tree
https://github.com/astanway/Commit-Logs-From-Last-Night/blob...
that reveals this page as a way to add your repo to the logs: http://www.commitlogsfromlastnight.com/submit.php
that reveals this page as a way to add your repo to the logs: http://www.commitlogsfromlastnight.com/submit.php
my bad, I think that was intended but never finished. the bit in that file gets the latest stuff on github irrelevant of the submitted repository.
alright, emergency hacking done! you can now add your username to be scraped :)
To much of offence in the languages.
-
crap.
API? I want to add my own stuff ;)
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.
hurr i'm swearing on the job. I'm crazy, me
newb commit msg: <nocomment>
uber commit msg: fuck
uber commit msg: fuck