Last wednesday we were given the opportunity to present a graphical version of our Hanabi work to the faculty at the university. Our setup involved 2 human players and two AI players.
As you may be aware, FOSS Galaxy recently acquired a Dedicated Box to replace some of our VMs. For those of you interested in the technical details:
My previous post got trac setup and running with SVN as the version control system. This post will show you how to get trac working with git as the version control system. When you installed trac using the command in the last post you will have also installed the trac git plugin. If you did not do so then you can set it up by running the following:
$ su -c "yum install trac-git-plugin"
It also assumes that you have it installed, If you don’t you can install it using:
$ su -c "yum install git"
Creating a git repository
In order to get trac to use the repository you have to set it up first. In this howto I will set up a local repository as the trac server is on the same machine I do development work on. You can use ssh to commit to the git repository remotely. There are many guides online on how to do this, so I won’t cover it here. You can create the folder to store your git repo anywhere, by convention they usually end in .git, and to keep everything contained I’m going to store it in my trac directory.
$ cd /home/webpigeon/trac
$ mkdir repo.git
$ cd repo.git
$ git init --bare
Setting up Trac-Git
Now we have the git repo setup (although empty) we can now setup the Git Trac plugin. This process involves editing the trac configuration file in your favourite editor. The editor I’ll use it vi, but you could use emacs, nano or a graphical editor like gedit if you prefer.
$ vi conf/trac.ini
First we have to enable the git plug-in. The easiest way to do this is to locate the “[components]” section in trac.ini. I couldn’t find this in my version, so I added it. This will enable the git plug-in. If you don’t do this step you will get a lovely warning message when you use trac stating, “Warning: Can’t synchronise with repository “(default)” (Unsupported version control system “git”: Can’t find an appropriate component, maybe the corresponding plug-in was not enabled? ). Look in the Trac log for more information.”. If you have added the below and you still get the error check that you installed the plug-in back in step 1.
tracext.git.git_fs.* = enabled
Locate the “[trac]” section in trac.ini. Under this section you will need to edit repository_dir and repository_type, there are plenty of other options in this section but you can ignore them. Repository type should be set to the full path to your repository which you just created and repository type should be set to git. If your path includes spaces you should probably put it in quotes, to be on the safe side (although I’ve not tried this).
# other stuff is here
repository_dir = /home/webpigeon/trac/repo.git
repository_type = git
# ... and here
Start the trac daemon and test it works
At this point your trac should be using your git repo for it’s ‘browse code’ section.
$ tracd --port 8000 --auth="*,conf/users.digest,trac" .
You should be able to view the code at http://localhost:8000/mouse-trac/browser. If you see your code (or a message telling you “No changeset HEAD in the repository” if you haven’t pushed your code yet) then congratulations you’ve set git and trac up. The git plugin provides a number of options, but the defaults are pretty sane so I’m sticking with them, if I find any problems/interesting configurations I’ll let you know.
[footnode] Remote Git over SSH
Just a quick, “how do I set-up my client repo” as a friend asked about it. After doing the following from your local git repo, you can just use “git push” to push to your remote server (trac). The “FlapJack” is the name of the VM I host my local trac in.
$ git init
# do work ...
$ git commit -am "inital commit"
$ git remote add origin ssh://webpigeon@FlapJack/~/trac/repo.git/
$ git push origin master
Going to http://localhost:8000/mouse-trac/browser should now show you your lovely committed code.
For additional commiters/computers you can then use:
$ git clone ssh://webpigeon@FlapJack/~/trac/repo.git/
If I’ve missed anything or something doesn’t work let me know in the comments and I’ll fix it. Hope this helps.
Did you know you can use Git to submit patches to projects via email (or website)? Thanks to Bruce I not only found this out but I also found out how to merge the patches as well. In this post I’m going to show you how to do it. There are quite a few uses for this, for example you might want to use this method for submitting patches to a bug tracker or to allow someone to contribute without giving them direct commit access to the repository.
Firstly you’ll need to grab yourself a copy of the repo for the project you want to write a patch for. This is a pretty standard thing to do.
$ git clone git://github.com/schacon/simplegit.git
Next you make your changes and commit them to your repository, again something standard for git users.
$ git commit -am "added foo to component bar"
Now the interesting bit, we’re going to generate a series of patch files we can send to the owner of the repository. The following command will take all commits which are not in origin (the place you got the repo from), with one commit per file.
$ git format-patch
You can then attach these patch files to a bug tracker, email or whatever you like using a version control. There is also a git command to send email but I’ve never used it so I can’t comment on it’s use. It’s git-send-email.
On the other side of equation there is merging of the patches. There are multiple ways to do this and a few useful commands related to it. The first command tells you how much how much the patch changes. Check checks if the patch can be applied cleanly. If the patch can be applied then you can use either ‘git apply’ or ‘git am’ to apply the patch.
If you use git am you can supply –signoff to let people know that the patch is approved. You can also supply -3 if the patch fails it will allow you to merge changes and use git am –resolved to mark the merge as resolved.
$ git apply --stat my_patch.patch
$ git apply --check my_patch.patch
$ git am -3 --signoff < my_patch.patch
git am --resolved# if the patch needs merging to take place