Move along, nothing to read

I wanted to document how to deal with an annoying corner case with git-submodules here. This applies in two variations:

• Changing the URL of a submodule to another tree with different ids (eg, two different git-svn conversions of the same SVN project).
• Converting an entire existing directory to a submodule.

If you apply the changes to all of your branches right when you make them, they are easy to do, but if you have old rotting branches, and you haven't kept them up to date, you can run into fun errors like the following:

fatal: cannot read object c1a25b84627516da46b6c375f4dc874deedbb597 'vendor/plugins/rspec~a4c30e94d52232e958d4f53c6a633ed438c54bcc': It is a submodule!

"vendor/plugins/rspec" already existed as a directory in this case. So how to do we work with this problem?

1. Look at the "git log ${PARENT_BRANCH} .gitmodules". Every time there was a change to the file, make a temporary tag. I suggest using tags with date+time in the name, as you will be making more tags in a bit. You should do this on the branch that is the parent of the branch you want to fix, to cut down on conflicts.
2. Next, identify spots that directories were deleted immediately prior to conversion to submodules, or between submodule URLs. Also tag these.
3. Edit your .git/config, and comment out ALL submodule references.
4. Now one at a time, issue "git pull . tags/${TAGNAME}", for each of your temporary tags, in order.
5. If you hit conflicts, fix them up as usual (edit files, "git-update-index ${FILES}", "git commit -F .git/MERGE_MSG")
6. If you think you messed up, use "git reset --hard ${COMMITISH} && git clean -f" with a known good point to reset you.
7. Remember to clean up your temporary tags afterwards.
8. Do "git submodule init" again.

I don't see why Git couldn't be made to do this automatically, since the process is reasonable simple, if a bit long to do by hand.

A few days ago, nicoj posted about using Gitosis on Gentoo, and as the developer that put the package into the tree. However, I don't think he realized at the time, that the Gitosis I packaged up, does differ from the original upstream version.

Why is is different? It is different because I decided to use Gitosis to power the new Gentoo Overlays, and found some limitations with Gitosis, so ended up hacking the codebase heavily to make it do what I wanted. It seems my original Christmas email to the upstream author went AWOL, so I wrote him another in the meantime. I hope that he will be able to merge the changed sanely, and make life easier for evertbody.

So what's different? A lot. Here's a partial list of the big stuff that is actually visible to most folk

• Relative git+ssh:// URLs! The original Gitosis required that you use : between the hostname and the repository for a relative URL, and assumed that you were using an absolute URL otherwise. This made URLs look a bit ugly, and also broke some classical URL parsers that expected a port number after the colon, then a path after the slash. So now Gitosis supports git+ssh://HOST/REPO style URLs, where the REPO is looked up directly in the Gitosis config to see if it is a valid relative URL.
• gitosis-init, you can use the default STDIN input of your key, or you can use actual command-line arguments: gitosis-init --adminkey=FILE --adminname=STRING. The latter argument is for when then username portion of your SSH key does not contain anything useful to you, and you wish for gitosis to place it in a more suitably named file in the keydir/ set of SSH keys.
• Handle SSH keys intelligently, validate the algorithm, supporting both SSH1 and SSH2 keys, extract the username (the field is actually a comment per the RFC) safely if possible, and handle the options correctly. Amongst the options, the from field of the key is now preserved, so that if you had a key (without a passphrase for example) that was limited to login from a certain location only, it does not become less secure.
• Allow setting of the initial directory permissions, globally and per-repository. Gitosis used chmod 0750 on directories it created before, which caused problems if you were running git-daemon as nobody:nobody. For the Gentoo overlays, the default repos now use 0755. If you set this globally, you should ensure that your gitosis-admin repo gets dirmode=0750, so that it does not get shared out by gitweb or git-daemon.

There are also two pending TODO items that I have for the Gentoo Gitosis-powered Overlays

• Gitweb has broken owner strings when UTF8 is involved
• The permissions handling needs an overhaul, adding a repo presently requires adding two config sections, each with 3 lines long. I'd like to refactor and make the [repo ...] section get a single line extra for the common case, which would totally do away with the [group ...] section per repo. Groups would remain JUST for defining groups, and the [repo ...] sections would get the lists of members and groups directly.

On a total lark, something like Gitosis for managing SVN users would be great too.

2008/08/03: Comments have now been disabled due to the amount of spam comments on this post. Email me if you have something useful to say.