marcus ramberg

12:27 <ribasushi> a call to all git-heads

12:28 <ribasushi> recently haarg did a seemingly perfect conversion of dbic from svn to git (a non-trivial feat)

12:28 <ribasushi> I am calling for people who actually know git to randomly poke at the new history and notufy me of whatever problems they see

12:28 <ribasushi> http://github.com/haarg/DBIx-Class

12:29 <ribasushi> (also you can ascertain the quality of the conversion, and potentially draft haarg to do a catalyst conversion as well – it took him a couple of freaking hours to do dbic)

12:32 <marcus> awesome

12:32 <marcus> haarg++

12:33 <marcus> it looks freaking good

12:33 <ribasushi> marcus: please spread the word to get more eyeballs on this, if nothing pops up in the next day and a half we’ll be  switching dbic over

Consider this me having spread the word to you ;-)

Github is probably much of the reason we love using git at Nordaaker. The great overview and administration system, as well as the simple no-nonsense issue tracker works very efficiently for us. Now github has added another feature that I think will help us collaborating efficiently on code.

Inline commit notes lets you comment anywhere in a commit, lending itself to quick code reviews and clarifications.

Yuval takes our hand and guides us through the proper process for migrating your SVN repository to Git:

Having an accurate revision control history is very helpful for tracking down regressions. Here’s my take on how to do this properly.

Hopefully someone can use this to migrate over Catalyst-Runtime to our spanking new Catalyst git repository.

GitHub created a headache for themselves at the initial launch of their inhouse hosting option for companies wanting to use GitHub.

That, coupled with the fact that we wanted companies to sign an NDA before receiving their quote, slowed the entire process down. It also bewildered more than a few people wondering why lawyers needed to be involved just to figure out how much the product cost.

Well, now they are up for everybody to see, but boy, with prices like that, I can see why they would like to keep them secret. $600/user/year. First year up front. For us, having 5 accounts, which is what we get with their ‘Small’ plan, it would be an upgrade from 144 USD to 7200 USD per year. After the first year we’d have to add 750$ a year if we want standard support. I doubt this is a very viable plan for most development shops. Specially considering Gitorious is open source.

Even though we’re currently using github for all our git hosting needs, we do like the open source alternative gitorious. It makes us happy that it’s now officially supported by some of our favorite rubyists from Oslo.

Gitorious now is a project maintained by Shortcut AS, which I co-founded. Shortcut AS now officially supports and develops Gitorious in cooperation with contributors outside Shortcut. Gitorious is, and will continue to be, 100% free software, licensed under the Affero GPL.

With my open source hat on, I am looking forward getting Catalyst moved over to Git in the near future. Hopefully we can get a nice gitorious setup for both Moose and Catalyst.

A few week back, I commented some concerns about git causing silos. I think this is a really good post by chris from github, illustrating the advantages of fully distributed development:

It may seem strange, and perhaps even like a lot of work. “Why should I have to check to see which is the most current? In the old model, there’s always a canonical repository.”

In the old model, actionwebservice wouldn’t have made it past 1.2.6. Welcome to distributed version control.

Think remote branch management is a hassle with git? This nice ruby-based helper should sort you out:

$  sudo gem install git_remote_branch
...
$ grb

To get a quick explanation of how it works. Or read on at Git Ready

Simon Wistow worries that the distributed nature of git results in fragmented software projects:

That model works well for Linux. Maybe. I’ll presume it does. Git eases the pain points expressed by Andrew Morton, the maintainer of the -mm tree, in this message entitled “This Just Isn’t Working Any More”

In short, it makes siloing easier.

My immediate reaction to reading his post was to think of the old saying ‹‹Guns don’t kill people, people kill people››. In fact, my experiences with forks so far has been two cases of forking repos on github, and doing a pull request to the author when my fixes were fit to be included in the main distribution. In both cases the authors included my changes in their versions.

Just because there exists a lot of works-in-progress doesn’t mean that they represent different authoritative versions of a given module. The situation for the rails OAuth plugin might be a bit muddled, but thanks to github’s excellent network map, it’s easy to track all of the 12 forks on github (substansially less than 27), out of which most seems to have merged into a new mainline.

It is clear that this project suffers from a inactive maintainer, but I believe that Git forks has lowered the barrier to contributing substantially, thus ensuring vitality for open source software projects. Our own Catalyst OAuth support, which resides in SVN is still non-working, despite several promises from people to look into it. These people might have working support in their local applications, but if that is the case, I’m unable to get to them or merge it into the started efforts in Catalyst SVN.

To summarize, Git lowers the barrier to contribution. Building or avoiding silos is up to the software maintainers, and giving support for patched versions is madness any way we look at it. Just the same way as developers are on their own when they use development versions of software, they can’t expect support for forked versions of that software either. If you live on the bleeding edge, you are going to bleed a little.

Nice hack by Miyagawa. I’d prefer if Perl continued to have a distributed delivery mechanism tho :-)

Great tip about using rebase when you pull from remote to get a cleaner git commit timeline.