Archive for the ‘git’ Category

VigetHub

Friday, April 4th, 2008

I’m excited to say that Viget’s open source participation is being bumped up a notch; last night, I created a new GitHub account for the company, where we’ll be hosting all our open source projects.

The general strategy is to use the vigetlabs repositories as the “stable” version for each of our projects, while the primary developers for each project will own a forked “edge” version. This will allow people to follow whichever version they’re more comfortable with, and hopefully encourage more participation from interested developers in the community. As an example, sandstone’s stable repository is at http://github.com/vigetlabs/sandstone/tree/master, and the edge version is at http://github.com/bscofield/sandstone/tree/master.

We’re still in the process of getting things up, but we hope to be finished soon. Take a look! (And look for more information soon on Viget’s development blog.)

Posted in git, open source, viget | No Comments »

A quick git-svn tip

Friday, February 1st, 2008

Updated!

When preparing to merge a working branch back to master (so that you can push it up to your SVN repository), the following process may be helpful:

> git checkout -b working
[work work work]
> git commit -m “helpful message”
[work work work]
> git commit -m “another helpful message”
> git svn rebase (pull down others’ updates - this is the updated step)
> git checkout master
> git svn rebase (pull down others’ updates)
> git merge –squash working
> git commit
[delete metadata, leave helpful messages]
> git svn dcommit

The output of all that is an SVN commit reading:

Squashed commit of the following:
another helpful message
helpful message

If you supply an explicit commit message to the last git commit (the one in bold), however, it will override your squashed messages and your SVN log will show only the final outcome, instead of all the steps you took to get to it. Of course, you could also leave the metadata from the squash - but that ends up generating a lot of noise in the SVN log.

Updated!
If your working and master branches are on different SVN revisions, you’re more likely to run into trouble during the merge, so it seems like a good idea to rebase both before trying to combine the two.

Thanks to my coworker Clinton for this addition!

Posted in git | 2 Comments »

Contributing to Rails with Git

Thursday, January 17th, 2008

I’ve been experimenting lately with git - a distributed version control system (DVCS) that’s been gaining popularity over the last few months. Git’s got a couple of fantastic features, but for me - coming from SVN - there were a few stumbling blocks. Despite the wealth of documentation and tutorials on the web, though, I was unable to find exactly what I needed online, so I thought I’d record it here so that others don’t have to search so much.

Setup

I used this post as a guide to installing git on my local machine. Unfortunately, I wasn’t smart about it - as it happens, the code there gives you an older release of the software that made my life harder in the long run. If you want to avoid those issues, try this instead:

curl http://kernel.org/pub/software/scm/git/git-1.5.3.8.tar.gz -O
gunzip git-1.5.3.8.tar.gz ; tar -xvf git-1.5.3.8.tar; cd git-1.5.3.8
make configure
./configure --prefix=/usr/local
make all
sudo make install

After that, proceed as the original post recommends (setting your PATH and the name and email defaults).

As for gitifying my Edge installation… that was easy. I just used the examples from this post, and I was set.

Contributing

Previously, I had an edge_rails folder that I checked out http://dev.rubyonrails.com/svn/rails/trunk to. When I wanted to patch Rails, I’d svn up to ensure I had the latest codebase, make my changes there. When I was satisifed, I’d then run svn diff > ../patches/appropriately_named.patch and submit that to Trac as a new ticket.

With git, the process is a little different. First, I create a new branch for the functionality I want to work on. For instance, when I’m working on grouping by multiple fields in ActiveRecord::Calculations (this patch - comments and +1s welcome!), I might do git checkout -b multiple_field_group master, which will create a new branch with the contents of master (which is Edge) and switch to it.

At this point, I can do whatever I need to - committing as I go, since my repository is stored locally - until I’m happy. Once I’m done, I can generate the patch with git diff -p master > ../patches/appropriately_named.patch; the -p option makes it a unified diff, just like svn diff produces. The core team has gone on record (in #rails-contrib, if nowhere else) as saying that they’re fine with git patches created in this way, so from there it’s just the same as before - upload to Trac and wait for the +1s to roll in.

Who cares?

There are a couple of big benefits to using git in this manner. First, I can develop complex patches much more easily by committing to my local branch as I go. Also, I can have multiple patches in the queue all at once, each living in its own branch. This means that I can keep patches up-to-date as Edge is updated more easily, too.

All in all, using git to manage my contributions to Rails is a huge win - and I’m evangelizing it to anyone who’ll listen. Go forth and gitify your Edge!

Posted in git, ruby and rails | 1 Comment »