Categories

A sample text widget

Etiam pulvinar consectetur dolor sed malesuada. Ut convallis euismod dolor nec pretium. Nunc ut tristique massa.

Nam sodales mi vitae dolor ullamcorper et vulputate enim accumsan. Morbi orci magna, tincidunt vitae molestie nec, molestie at mi. Nulla nulla lorem, suscipit in posuere in, interdum non magna.

amaro(c)king git

Lately Git was (and still is) one of the hot topics in KDE land. After Qt has moved to gitorious.org for their public repositories, one question for KDE is where to host the KDE repository – on KDE infrastructure or for example also on Gitorious?

The Amarok team decided  they want Git rather now than later. This is why their SVN-repository is now read-only and you can find Amarok on Gitorious. I talked with Lydia a bit about this and we figured it would be good to see how it works and checked how someone external to the project would submit code by creating a merge request.

This is not what a regular contributor will want to do for the usual bug fixes if they are straight forward.

Creating an account on Gitorious is as easy as it gets – pick a name and password and you are done. If you happen to have a KDE-SVN account you might want to ask one of the KDE Admins on Gitorious to add you to the KDE-developers group, but that is not what I had in mind for my test.

Choose any project on Gitorious that you want to work on and start by creating a clone.  Remember, we look at it from the “external patch contributor” side. If you simply check out the existing repository, you will not be able to push your changes (unless you are in the right group and use the right url). You will also need a ssh key pair in order to push changes back. This is similar to working with ssh in the KDE svn repo. ssh-add will still work therefor 😀

In my case choosing the project meant going to http://gitorious.org/amarok. Next select the branch I want to work on, which is “trunk” or “HEAD” (in git talk), in case of the Amarok repository called “amarok – Mainline”. I am logged in to Gitorious, so I see a button to clone the repository (and on the way I get asked to add my public ssh key, so a secure connection for pushing and pulling can be established).

Clone this ripository on Gitorious

That’s what I want, so I get my clone of Amarok. Next step – check it out – or better “clone” it.

There are two urls that the page of my clone shows, one public that everyone can clone and the other that let’s me push my changes.

amarok_new_repo

When starting to work on it, you want that url, I’ll

git clone git@gitorious.org:~frederik/amarok/frederiks-clone.git

Creating a commit just for the sake of testing seemed stupid, so I sat down and added a little feature that I find actually useful. “Stop playing after this track” has been available in the playlist for a while now. But I usually don’t  bother opening the Amarok window just to find the current track and right click it to make Amarok stop playing after this song. It usually happens that when I’m listening to music and I have to leave a few minutes later, I find  the current song is just great. Since this will most likely also be the case for the next song, I’ll never be able to leave. So I need a global shortcut to help out in this situation… “stop playing after current track”.

I create a branch and check it out:

git branch stop_playing_after_this
git checkout stop_playing_after_this

Compile it once to make sure, start adding my changes. Since I don’t know the Amarok code, this took me a few extra minutes. Now my patch is ready and it’s just hackish enough to get a rebuke from my favorite Amarokkers in which case I can see how the commenting on merge requests in Gitorious works 😉

Commit my changes:

git commit -a

Now it’s time to get it out into the interwebs  (or Gitorious at least):

git push origin stop_playing_after_this

One mistake I made was when I tried to push my changes was pushing master instead which is just my checkout (which I had updated to a newer revision at this point. Not what I wanted.

git push origin master

I documented some of the steps on techbase in the patch contributor section: http://techbase.kde.org/Getting_Started/Sources/KDE_git-tutorial Most of the docs are written by the Amarok people themselves though.

In my opinion, Gitorious seems like a great option for KDE. A few points are still lacking though. For example I wouldn’t know how to get notifications about commits in a branch that I’d like to watch (similar to what commit-filter does), but that’s something that will come, I bet [I’m told eean works on this already and there are rss feed in the meantime]. And at the moment there is not possibility to close bugs on bugs.kde.org with a commit yet. So no big points really, just minor annoyances.

Well behaved Git use means having the first line of the commit message to be a short summary… and to see this line in Gitorious you need to click on the “1 commit” part of the log.

And then we were wondering who would get notified of the merge request. Since Chani just responded, it seems that for now, all people in the KDE-developers group get notified, which is maybe a bit too many for an Amarok commit, so that needs to get sorted out.

All in all, I’m really happy with this, pretty much everything worked as expected, but it sure takes some time to wrap your head around git. Sending a patch by mail would have been faster for this example, but since I need to polish it up a bit, now I have much better tools at my hands in order to do that. And compared to using git-svn this was all painless and easy 🙂

Thanks and congratulations to the Amarokers for being brave.  And for helping me get the git stuff right.