The author’s mention of BuzzFeed in the first paragraph made me think of something terrible/hilarious. Maybe we should write the first line of commit messages not as a summary, but as a clickbait title which encourages the reader to read the rest of the commit message. For example:
“This one cool trick to improve network performance”
“Added 8 new log messages. You won’t believe #1”
“One new configuration option that QA people hate”
AFAICT these all basically agree on the major points. I think this topic will keep coming up approximately forever because it takes a certain amount of discipline and/or enforcement.
First, it needs to be short, and not just because brevity is the soul of wit.
No no no no! Make your commit messages long! Very long! As long as you can make them! Explain the whys, the wherefores, the causes, and the effects! Write a novel if you can! Tell us how you really feel about the code! Coupled with annotate/blame commands, your commit messages now become your developer documentation. Consider that your VCS forces you to write documentation every time you make a change, so document as much as possible. Most of the time this documentation is out of the way unless you explicitly invoke it.
You should also lead with a one-line short summary, no longer than 80 characters. Exercise your soul of wit here, explain as much as you can in as little space possible for your one-line summary. The summary is what you’ll see with git log --oneline or with hg log by default. Also, wrap your commit messages to 80 characters so they’re viewable anywhere.
The commit messages for the Linux, git, and Mercurial repos are great examples of what commit messages should look like.
Please don’t. It is not helpful here. Most of the submitters are not the authors of the stories and have no control over whether they are accessible over Tor.
I’ve enabled a “view cached” link under each story when browsing through the Tor onion site that will take you to the archive.is version of the URL, which is being requested for each new story submitted going forward. Now you have no reason to complain.
it has been interesting, though, from the standpoint of someone who doesn’t have to use Tor. what percent of the world does, and how many lobsters deal with this on a daily basis?
does anyone have any resources on what causes this? is it intentional or just insufficient configuration at some level?
I imagine it would have to be intentional (to detect a Tor user you typically need to make an effort to detect whether the connection is coming from a Tor exit node); perhaps they received a spate of anonymous comments via Tor and decided they would block all the service’s users instead of actually solving the problem.
The author’s mention of BuzzFeed in the first paragraph made me think of something terrible/hilarious. Maybe we should write the first line of commit messages not as a summary, but as a clickbait title which encourages the reader to read the rest of the commit message. For example:
I’ve generally pointed people towards http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
There’s also http://chris.beams.io/posts/git-commit/
I’ve seen some conference talks that cover it as well. http://confreaks.tv/videos/rockymtnruby2011-lightning-talk-do-your-commit-messages-suck and http://confreaks.tv/videos/rubyconf2015-communicating-intent-through-git come to mind
AFAICT these all basically agree on the major points. I think this topic will keep coming up approximately forever because it takes a certain amount of discipline and/or enforcement.
You may want to submit some of those as stories, I haven’t seen them before. ;)
No no no no! Make your commit messages long! Very long! As long as you can make them! Explain the whys, the wherefores, the causes, and the effects! Write a novel if you can! Tell us how you really feel about the code! Coupled with annotate/blame commands, your commit messages now become your developer documentation. Consider that your VCS forces you to write documentation every time you make a change, so document as much as possible. Most of the time this documentation is out of the way unless you explicitly invoke it.
You should also lead with a one-line short summary, no longer than 80 characters. Exercise your soul of wit here, explain as much as you can in as little space possible for your one-line summary. The summary is what you’ll see with
git log --onelineor withhg logby default. Also, wrap your commit messages to 80 characters so they’re viewable anywhere.The commit messages for the Linux, git, and Mercurial repos are great examples of what commit messages should look like.
[Comment from banned user removed]
[Comment removed by author]
[Comment from banned user removed]
Please don’t. It is not helpful here. Most of the submitters are not the authors of the stories and have no control over whether they are accessible over Tor.
[Comment from banned user removed]
I’ve enabled a “view cached” link under each story when browsing through the Tor onion site that will take you to the archive.is version of the URL, which is being requested for each new story submitted going forward. Now you have no reason to complain.
I don’t think your posting this on every lobste.rs story which can’t be viewed through Tor will actually improve your situation.
it has been interesting, though, from the standpoint of someone who doesn’t have to use Tor. what percent of the world does, and how many lobsters deal with this on a daily basis?
does anyone have any resources on what causes this? is it intentional or just insufficient configuration at some level?
I imagine it would have to be intentional (to detect a Tor user you typically need to make an effort to detect whether the connection is coming from a Tor exit node); perhaps they received a spate of anonymous comments via Tor and decided they would block all the service’s users instead of actually solving the problem.
[Comment from banned user removed]
They seem to only block certain exit nodes: https://support.cloudflare.com/hc/en-us/articles/203306930-Does-CloudFlare-block-Tor-
Looks like there was a proposal to try and address this from within the Tor community a couple of years ago: https://blog.torproject.org/blog/call-arms-helping-internet-services-accept-anonymous-users Not sure what came of it.
I suppose Medium could use this: https://github.com/DonnchaC/cloudflare-tor-whitelister
[Comment from banned user removed]
Try another exit node.
[Comment from banned user removed]
Your life sounds hard.