Technical Pickles

Git seems to be getting a lot more attention lately. I started using it here and there, and I'm pretty enamored with it so far. Here are some links to get you started.

• Peepcode's Git screencast: I bought a 10-pack of peepcode screencasts several months ago. Definitely worth it. This one in particular is very informative and gives you a good walkthrough of doing your day-to-day type tasks.
• Using Git to Manage and Deploy your Rails Apps (screencast)
• Setting up a new remote Git repository
• Hosting Git repositories the easy and secure way: Gives a walkthrough of managing repositories using gitosis
• Sharing Git repository via OS X's built in web sharing: For when you want to ad hocly host repositories, like if you're at a hackfest, for example.

In my last post, I was making Git out to be kind of a big deal. One of the links talked about setting up gitosis for managing repositories. It's an excellent walkthrough, but it's pretty generic. This post hopes to provide a Gentooified version of it.

The scenario

I'm making a few assumptions:

• You have a workstation with a normal user, with hostname 'urworkstation' and user 'you'.
• You've installed dev-util/git on urworkstation.
• You have a server with root access, with hostname 'urserver'.
• You will be making a repository called 'gitftw'

Installing gitosis

Gitosis is a fairly recent addition to portage. If you're not using ~arch for your ACCEPT_KEYWORDS, you will need to add an entry to /etc/portage/package.keywords.

root@urserver # echo "dev-util/gitosis" >> /etc/portage/package.keywords

Now you should be able to emerge it.

root@urserver # emerge -atv dev-util/gitosis

Note: -t shows a dependency tree of what will be merged, -v includes a little more verbose output, and -a shows you what will be merged, and asks you to continue.

This should (hopefully!) merge without any issues. It installs all the gitosis files you need, as well as create a 'git' user and group, and a place for your repositories to live in at /var/spool/gitosis/repositories.

You now are ready to start configuring gitosis.

Configuring

You'll need to generate an ssh key, if you don't already have one. I also recommend using keychain for managing your keys/ssh-agents.

you@urworkstation $ ssh-keygen -t rsa

You will be prompted for a location to save the key, but I will assume you choose ~/.ssh/id_rsa. This will create ~/.ssh/id_rsa and ~/.ssh/id_rsa.pub. Now you want to toss id_rsa.pub up on urserver using scp.

you@urworkstation $ scp ~/.ssh/id_rsa.pub root@urserver:

After you get id_rsa.pub there, the following command switches to the git user, and kicks off gitosis-init using your ssh public key.

root@urserver #  sudo -H -u git gitosis-init < id_rsa.pub

Note: -H makes sudo switch the user's home directory. -u git says to switch to the git user.

This creates the gitosis-admin repository which you will use to further setup gitosis.

Now you want to clone it:

you@urworkstation $  git clone git@urserver:gitosis-admin.git

Creating new repositories and adding users

The creating of repositories and adding of users isn't really Gentoo specific, so I refer you to the "Creating new repositories" and "Adding users" sections of the gitosis article.

I assume you'll create a repository called 'gitftw', and give yourself access to it.

Making publically accessible using git-daemon

At this point, you have your 'gitftw' repository, and you're able to clone it by doing:

you@workstation $ git clone git@urserver:gitftw.git

This is all well and good if you want only users you've setup to be able to access the repository. But what about if you want to provide anonymous access to the repository? One answer is to use git-daemon which comes as part of git.

The Gentoo package for dev-util/git provides an init script for you, so you just need to tweak the accompanying conf file, and add it to the default runlevel.

There are two ways you can choose to export your repositories. The first is to individually choose which repositories to export, or choose to export everything by default. I think the latter isn't the best idea though, since this includes gitosis-admin repository.

Selectively export

Open up /etc/conf.d/git-daemon, and update it to have:

GITDAEMON_OPTS="--syslog --base-path=/var/spool/gitosis/repositories/"

Now we touch a file 'git-daemon-export-ok' in each repository we want exported.

root@urserver # touch /var/spool/gitosis/repositories/gitftw.git/git-daemon-export-ok

Export everything

Open up /etc/conf.d/git-daemon, and update it to have:

GITDAEMON_OPTS="--syslog --base-path=/var/spool/gitosis/repositories/ --export-all"

Starting it

You're all set to actually start it up now.

root@urserver # /etc/init.d/git-daemon start

Now we try checking it out using the git protocol:

you@urworkstation $ git clone git://urserver:gitftw.git

Assuming all is well, now we can add it to the default runlevel.

root@urserver # rc-update add git-daemon default

Conclusion

Congratulations, you are now all set to manage and play with git on urserver until the cows come home.

Update Jan 22, 2008

Robin Johnson aka robbat2, who maintains the ebuilds for gitosis, posted some important notes about our gitosis package. Mostly, there are some differences between our package and the upstream version of gitosis.

I've been using git a lot more since my last set of git links.

• Cheat sheet from Err the Blog.
• Another cheat-sheet type deal. Includes lots of useful alias and other configs.
• Dealing with branches, remotes, and merging
• For when you have to change where your 'origin' repo lives

There are hosting options available, even if you don't want to setup something up yourself. I've only used GitHub myself, so I can't speak for the others

• GitHub: Currently in invite-beta mode (no, I don't have any more invites)
• repo.or.cz: provides public hosting
• Gitorious: targets open source projects

It seems like lots of Ruby projects have been switching to git recently. Here's is an example of people using and promoting development through the distributed magic of git:

• Contributing to Merb (Part 1)
• Contributing to Merb (Part 2)

I don't think many people are aware of it, but Gentoo Prefix is a valid alternative to MacPorts and Fink for installing unix-y type software on Mac OS X.

Personally, I just use it to install all those command line tools and utilities I miss from Linux.

Here's my development-centric laundry list of things I've used it to install:

• version control
  
  • cvs
  • darcs
  • git
• Java stuff (yep, it supports Java using Apple's SDK)
  • ant
  • maven
• Others
  • nmap
  • keychain

So remember kiddies, Gentoo works on Mac OS X too!

If you hadn't heard, GitHub went officially live last week.

As I've posted before, git is pretty awesome. GitHub makes it even better.

In honor of the launch, here's a quick rundown of forking a repository to start hacking away.

First off, you need to find a victim. In this case, I'm going to go after thoughtbot's Shoulda.

First navigate to the repository, and click 'fork'.

Give it minute while the hardcore forking action happens. Now you have your own fork of the repository.

Here you can see your clone/push URL. So we should go ahead and clone it:

git clone git@github.com:technicalpickles/shoulda.git

So we have a checkout now. As is, it's kind of detached from the official repository. If we're going to be actively working on it, we should add the official repository as a remote.

cd shoulda
git remote add official git://github.com/thoughtbot/shoulda.git

From now on, we should be able easily pull in the changes:

git pull official master

So now what? Get hacking of course. But how do send our changes back? Well, this is a tricky question. There are several ways, but it mostly depend on those receiving the changes back. As people get more comfortable with git, I think we'll start to see some best practices emerge here.

After forking the recently gitified Shoulda, I started poking around. First thing I noticed is tests were failing because some directories were missing. Presumably, this is because git ignores empty directories.

Let's use this opportunity to using git and GitHub to contribute a fix for this, shall we?

Here's a sky high view of the process:

• Create a fix branch
• Make changes
• Push fix branch to GitHub
• Browse to branch in browser
• Submit a 'pull request' to the maintainer for review

After the maintainer gets the request, they are free to do as they see fit. Accept it, tweak it, kick it, and so on.

Fixing it

First thing's first. We should create a branch off of master to isolate the fix:

git checkout -b add_missing_dirs

Now the tricky part: actually fixing it. When everything is ready, I just commit it:

git commit

As always, it's good to include meaningful commit messages. Keep in mind that if accepted, this message will become eternally bound to the repository.

With that out of the way, we actually need to push it to our 'origin' remote. This would be GitHub.

git push origin  add_missing_dirs

Requesting the pull

We can now go to our repository on GitHub. We want to browse to the add_missing_dirs branch. Mouse over 'all branches' to get there.

This gets us to the branch. Next, we indicate our desire to submit a pull request.

This prompts us for some details. I only had one commit, so I used its log as the message. I added tsaleh aka Tammer Saleh as the recipient, since he's the maintainer of Shoulda.

After you submit, you'll get a notice that it was sent successfully, and you'll be returned to your branch. The recipients now get a notice about this pull request, and can take appropriate action from there.

Done and done

Congratulations! You are now at the mercy of the maintainer.

Git changes the game when it comes to how you collaborate. GitHub even more so.

If you want to collaborate with someone on GitHub, you have three options:

• Add them as a committer
• Have them fork your repository, and you pull changes as appropriate
• Both

So which should you use? It depends.

If you will be working closely or in tandem with the individual, you might want to add them as a committer, allowing them to push to your repository at will. This is pretty comparable to how you might work with others on a subversion repo.

If it's more asynchronous work, forking would be more appropriate. This is particularly applicable to open source or large projects.

Of course, you could do both. They create a fork to use as their sandbox, and then you're able to push changes to your repository. I suspect that this is how the rails repo works, with the core team having access to it, but having their own forks.

Update:

As the fates had it, a somewhat related post titled 'To fork or Branch' was posted over at toolmantim.com.

Piston has had support for git (both importing from, and into) for a little over a month.

Before that, I felt like developing a rails app in git was a bit painful. Considering most plugins are kept in subversion, you're only real option is using svn export to install plugins, and check that into git. There was braid, but I really didn't have any luck with it.

But, like I said, it's all good now. It hasn't been officially released (ie as gems), but you can build and install it yourself easily enough.

$ git clone git://github.com/francois/piston.git
$ sudo gem install -y main open4 log4r
$ cd piston
$ sudo rake install_gem

Pretty straight forward to use.

$ cd vendor/plugins
$ piston import git://github.com/technoweenie/restful-authentication.git
INFO main: Guessing the repository type
INFO main: Guessing the working copy type
INFO main: Checking out the repository
INFO main: Copying from Piston::Revision(git://github.com/technoweenie/restful-authentication.git@42083ffa31e0a9792472780854ddd81bcc9b2f61)
INFO main: Checked out "git://github.com/technoweenie/restful-authentication.git" 42083ff to "restful-authentication"

And since it's since it's being developed in a git repository, and on GitHub, it's extremely easy to start contributing.

I mean, if I can contribute something, I'm sure you can pull it off too :)