Git and gitolite nirvana

January 21, 2011 3 Comments by Richard

Having recently begun switching all of my projects to use git for source control, I have been using gitosis on my server and have been pretty happy with it. However, the one thing that kinda annoyed me was that every time I wanted to create a new repository, I had to go add it to the config file.  I found myself making up excuses to just use a raw ssh to my server at home.  This, of course, was also a bit of a pain since I had to go set up a raw repository each time I wanted to do it…

Enter gitolite

Gitolite has a really cool feature that I make heavy use of called “wildcard repositories”. The way I use it, this lets me set up a group of users (@wildcardusers) that can create whatever arbitrary repositories they want in a subdirectory of the same name as their username.

In the gitolite.conf file:

@wildcard_users = richard jarom ben

repo    CREATOR/.*
    C     = @wildcard_users
    CRW+D = CREATOR
    RW    = WRITERS
    R     = READERS

Voila! I can now push to any repo looking like [email protected]_server.net:richard/my_repo.git

Setting the default remote HEAD

Ben and I happily used this for the better part of a day before we ran into our first disappointing snag. Ben is a huge fan (and I as well to a lesser extent) of git-flow, but with the layout we normally use with git-flow the default repository should be named “develop” instead of “master”.  Well, no problem, right?  A quick git checkout -b develop and we have a develop branch, then git branch -D master and the master branch is gone.  git push origin :master removes it from the gitolite server, and we’re ready to roll!

Oops! When we clone the repository, it clones okay but gives us an error at the end that it can’t find the HEAD ref. This is aparently a normal git configuration thing that has to be done on the server, but users who can create wildcard repositories shouldn’t need shell access on the box!

Fortunately, gitolite supports Admin Defined Commands (ADCs). They are suprisingly easy to use if you know a bit of shell script programming (or python, as I’ll explain later). As of a commit last night, there is now a set-head ADC in the contrib directory in the main repo.

ssh [email protected]_server.net set-head richard/my_repo.git refs/heads/develop

Simple as that, the HEAD is changed!  Note that ADCs have to be enabled and configured before you can use them.

Giving other users access to your repo

As you probably gathered earlier, this server is used by a small group of people who often work on projects together. Sometimes we need to give someone else access to our repository.  We might also want to just give access to anyone through the git:// protocol (which gitolite supports when configured correctly using the daemon user).

You can do this using the setperms and getperms built-in ADC.  However, these are a little inflexible for my tastes, and I had a few minutes, so I wrote a quick python helper class for writing ADCs and threw together the perms ADC, which is also in the main repo now.

You can run the command and see the help for yourself, but here is a quick example of what you can do:

[email protected]:~ $ ssh [email protected]_server.net perms
Usage: perms   
             list  [TYPE]
             clear 
             add   [user and group list]
             set   [user and group list]
             remove   [user and group list]

[email protected]:~ $ ssh [email protected]_server.net perms list richard/test.git
WRITERS:
    fred
READERS:
    ben
    jarom
[email protected]:~ $ ssh [email protected]_server.net perms add richard/test.git WRITERS billy
WRITERS:
    fred
    billy
[email protected]:~ $ ssh [email protected]_server.net perms add richard/test.git READERS joe
READERS:
    ben
    jarom
    joe
[email protected]:~ $ ssh [email protected]_server.net perms remove richard/test.git READERS jarom
READERS:
    ben
    joe
[email protected]:~ $ ssh [email protected]_server.net perms set richard/test.git READERS ben jarom
READERS:
    ben
    jarom
[email protected]:~ $ ssh [email protected]_server.net perms list richard/test.git
WRITERS:
    fred
    billy
READERS:
    ben
    jarom

2 Comments

  1. Ben
    6 years ago

    Nice writeup. However, my pain with ‘master’ and ‘develop’ branches seemed even more frustrating than you described it.

    The actual workflow that exposed the need for set-head to me was doing ‘git branch -m develop’ while on the master branch, followed by a ‘git push –all origin’ which created the wildcard repo.

    My HEAD was develop at the time I pushed. ‘master’ didn’t exist, and never had as far as gitolite should have been concerned. Yet somehow it still wanted my default branch to be called ‘master’ — frustrating to say the least.

    Thanks for whipping up your ADC to fix it so quickly, and congrats getting your contributions sucked into the parent repo — it’s nice to see a contribution accepted.

  2. FlyingYeti
    6 years ago

    FYI, I was struggling with a similar problem and found this blog post helpful, but the information is a bit outdated.  

    Sometime during gitolite 2.x development, the set-head command was replaced by the more flexible symbolic-ref command.  Gitolite 3 doesn’t yet have symbolic-ref, but sitaram (author of gitolite) whipped together this quick fix:

    http://dpaste.org/AgqKW/

    Copy to gitolite/src/commands/symbolic-ref, chmod +x, and add the command to .gitolite.rc in order to use.

One Trackback

  1. […] This post was mentioned on Twitter by Richard Bateman, FireBreath Project. FireBreath Project said: new FireBreath related blog post: : Git and gitolite nirvana http://colonelpanic.net/2011/01/git-and-gitolite-nirvana/ […]

Post a Comment

Your email is never published or shared. Required fields are marked *