git $something -p //at 16:09 //by abe

git add -p is one of my favourite git features. It lets you selectively add the local changes hunk by hunk to the staging area. This is especially nice if you want to commit one change in a file, but not a second one, you also already did.

Recently I noticed that you can also selectively revert changes already in the staging area using git reset -p HEAD. The user interface is exactly the same as for git add -p.

Today I discovered another selective undo in git by just trying it out of curiosity if that works, too: Undoing local changes selectively using git checkout -p. Maybe less useful than those mentioned above, but nevertheless most times quicker than firing up your favourite editor and undoing the changes manually.

Another nice git feature which I discovered by accidentially using it (this time even unwittingly) is git checkout - which behaves like cd -, just for branches instead of directories, i.e. it switches back to the previously checked out branch. Very useful for quickly changing between two branches again and again.

How to move a git submodule //at 20:31 //by abe

If you try to move a git submodule with git mv, you’ll get the following error message:

$ git mv old/submodule new/submodule
fatal: source directory is empty, source=old/submodule, destination=new/submodule

There’s a patch against git to supoort submodule moving, but it doesn’t seem to be applied yet, at least not in the version which is currently in Debian Sid.

What worked for me to solve this issue was the following (as posted on StackOverflow):

1. Edit .gitmodules and change the path of the submodule appropriately, and put it in the index with git add .gitmodules.
2. If needed, create the parent directory of the new location of the submodule: mkdir new.
3. Move all content from the old to the new directory: mv -vi old/submodule new/submodule.
4. Remove the old directory with git rm --cached old/submodule.

Looked like this for me afterwards:

 # On branch master
 # Changes to be committed:
 #   (use "git reset HEAD <file>..." to unstage)
 #
 #       modified:   .gitmodules
 #       renamed:    var/lib/dokuwiki/tpl -> var/lib/dokuwiki/lib/tpl
 #

Finally commit the changes. HTH.

Thoughts on Gitorious and GitHub plus a useful git hook //at 11:36 //by abe

When I took over the developement of xen-tools, I looked around for an appropriate git hosting. I especially had a look at GitHub and Gitorious.

If you just regard the features, GitHub is definitely more targetted on single developers and Gitorious more towards projects:

At GitHub, every repository has its URL under the URL of a user page which makes it nearly impossible to have user independent, “official” repositories for projects which have more than one official developer.

At Gitorious, every hosted repository needs to belong to a project, even if it’s only a published configuration. But a project can have more than one git repository. You only seem to be able to have personal repositories if you clone some existing Gitorious repository.

So from a feature point of view, the xen-tools git repositories fit way better to Gitorious’ hosting while the git repositories with zshrc, conkerorrc and desktop configuration files defintely have a more fitting addresses on GitHub, in my case http://github.com/xtaran/$repository. On Gitorious, they are now together under a “project” called “Axel’s configuration files” at http://gitorious.org/abe which contains git repositories of my on grml’s .zshrc based .zshrc, my configuration for Conkeror and all the files necessary for my ratpoison/xmobar based netbook/laptop desktop.

I though feel a little bad for giving the project the very short “slug” name “abe” instead of “abe-config” (as I did initially) since “abe” is IMHO not a proper “project name” for my configuration files and possibly other projects would have a more reasonable claim for that project name on Gitorious. But that way it suites more its purpose: Gather some of my git repositories which don’t belong to a proper project.

But there’s another important point when comparing Gitorious and GitHub: Free Software needs free tools as Benjamin Mako Hill posted recently on Planet Debian. Despite my (probably well known) distrust against Google and therefore also Google Code, and despite knowing the history of SourceForge becoming non-free, I was not that much aware that GitHub’s software is only partially open source and therefore also not free software while Gitorious is both as it’s licensed under the GNU Affero General Public License (like StatusNet/identi.ca for example) which is basically GPLv3, but its ideas applied to hosted web applications scenario (where the GPL itself doesn’t grasp), too.

Initially I just had the xen-tools git repositories on Gitorious and all my small one-repository “projects” as copies of the repositories on my own git server on GitHub to get some more publicity for them and allow “social cloning”. After reading Mako’s article, I decided to at least have repository clones on Gitorious of all repositories I mirror at GitHub, too.

That way I force nobody to use the non-free tools on GitHub for “social cloning” one of my git repositories. And of course I have copies of my code somewhere on the net as backup. Or to say it with Linus Torvalds’ (slightly updated) words: Only wimps use tape backup: real men just upload their important stuff on git, and let the rest of the world clone it. ;-)

But isn’t that tedious to always push your code to three repositories? No, it isn’t. I just push my code to git.noone.org where I have configured the according remotes and the following post-receive hook:

#!/bin/sh
                                                                     
read oldrev newrev refname
git push gitorious ${refname:t}
git push github ${refname:t}

The only other thing necessary is to use ssh-agent and SSH agent forwarding to at least the host you’re pushing to.