If folks have enough programming experience with other languages, it's easy to write Perl that looks more like those other languages, but unfortunately the moment a developer gets overworked or wants to show off (opposite extremes, really), Perl can devolve faster than some other languages because so many tricks are possible when vigilance is not maintained.
I've had decent success with making one-class-per-file with MooseX::Declare and Method::Signatures::Simple, but you really have to have a good code review process and rock solid developers to make it happen.
I don't think it's the languages fault, as this can happen just as quick in (say) Ruby code, and you can write extremely bad code in any language. Those other languages tend to be slightly faster to develop in though, as you can forget all of the need to write things like "my" and the reference syntax. Things like Python and Java have some resistance to "having fun with syntax games", but fall into other traps where interesting syntax (or architecture games) become fun or quick shortcuts.
On one end, part of Perl's problem is not Perl at all, just that it was historically the first thing people learned after Bash, and often those folks really didn't learn to program yet. On the other end, it is easy to go crazy with it.
Warning -- This article posts a longwinded first person account and finally ends with "this scenario is purely hypothetical". So it sounds like it is talking about a security vulnerability with git that really happened (signed commits or tags being broken, perhaps?), and it's actually an article saying you should use signed commits if you can't control access to your repo.
Key lines: "Somebody please look at the diff. Thats a simple 3 line code addition. I agree to you @torvalds but you could have excused this time :)"
AND: "By the way, its quite funny that github is sending instructions to @torvalds on using git."
Neither of which lines does Kenneth mention.
To me, this post is like the selective editing FOX News or the Colbert Report occasionally do to take things out of context.
Not a fan.
It's hard being a project maintainer. Linus was more than explanatory. This is the kernel, after all, dealing with github gen pop can be quite tiresome, and I don't blame him at all for not wanting people to be throwing rocks at him.
I believe you used to be able to click on the "forks" and "watchers" button to see who is forked or watching. Now the button defaults to "unwatch" when looking at the project page.
I find these new icons confusing as well. It took me a long time to figure out the one icon was an eye with a "X" on it for "unwatch". Not sure why the branches in "your fork" travel upwards as well, as I've never seen a source control diagram do that.
And my default user/organization/project icon is no longer an octocat but a book with a fork on it. I miss the octocat.
I think this is a classic problem when a graphic designer doesn't have enough meaningful real work to do :)
Yep, this is a pretty lame ranking system. Projects are given more points the more people are registered in them with accounts on the system.
Compare this with what Ohloh does, where someone can be ranked in the top #10 of contributors (or projects) without even signing up.
Ohloh doesn't offer very interesting stats, so I was expecting something more for stats junkies, but this is considerably worse in most all respects.
It will result in Flickr-like interestingness numbers, where people who play in the social network have more ratings, rather than a system that identifies the most important projects or the most widely active developers.
If folks are wanting to check this out, my work build some VMware appliances for it. You should be able to get the server running in just a few minutes. Anyway, in case it's useful:
I find the gh_pages branch confusing too -- the idea that a branch doesn't contain something related to the other branches feels weird.
What I've found is it's easier to create a free organization, and that way you can get a organization.github.com project created and host the pages there.... this is easier than juggling the spare branch. Obviously smaller starter projects should not do this, but you could use username.github.com/yourproject name and not keep the documentation on the branch just as easily.
Presto, no gh_pages branch, but all of the advantages of hosting web content.
Maybe it's just me, but using short lived topic/feature branches and squash merges seems much easier than remembering all of these steps to "fix up" all these things.
I think it becomes some what of a game to use all the more obscure corners of git when a good 20-30% of it goes a long way.
Cool. Here's another take on this, which doesn't produce quite as nice output, but produces some different stats and is Ruby based and a bit more objecty (if that matters). It doesn't like being fed the kernel but was fine on some very large software projects.