github
Advanced Search
  • Home
  • Pricing and Signup
  • Explore GitHub
  • Blog
  • Login

sitaramc / gitolite

  • Admin
  • Watch Unwatch
  • Fork
  • Your Fork
  • Pull Request
  • Download Source
    • 149
    • 15
  • Source
  • Commits
  • Network (15)
  • Issues (1)
  • Downloads (12)
  • Wiki (1)
  • Graphs
  • Branch: master

click here to add a description

click here to add a homepage

  • Branches (8)
    • big-config
    • master ✓
    • oldgits
    • progit-article
    • pu
    • pu-big-config
    • size-count-limits
    • ssh-plus
  • Tags (12)
    • v1.0rc1
    • v1.0
    • v0.95
    • v0.90
    • v0.85
    • v0.80
    • v0.70
    • v0.65
    • v0.60
    • v0.55
    • v0.50
    • nonstd-path-for-00
Sending Request…
Enable Donations

Pledgie Donations

Once activated, we'll place the following badge in your repository's detail box:
Pledgie_example
This service is courtesy of Pledgie.

standalone, souped-up (started with per-branch permissions as the only extra feature, now lots more), version of gitosis. In perl. [Note: ALL branches except master are subject to rebase/rewind :-)] — Read more

  cancel

  cancel
  • Private
  • Read-Only
  • HTTP Read-Only

This URL has Read+Write access

Merge remote branch 'origin/pu' 
Sitaram Chamarty (author)
Sun Jan 31 21:14:48 -0800 2010
commit  90fed7792746a9a33e24059fb171f6bbb6ffebe6
tree    34c8e3bc4a8bedc1f4d25f2c92556f2e542c1828
parent  c1de05a8a559827bd5f8f2b037c9e680a9c802fe parent  b4a65ab73ce7abeaccd5f23c5b0a77d069e029bc
gitolite /
name age
history
message
file .gitattributes Wed Nov 18 02:10:37 -0800 2009 all src/ and conf/: force crlf=input via gitatt... [Sitaram Chamarty]
file .gitignore Mon Sep 21 06:31:47 -0700 2009 Makefile wraps "git archive" to record "git des... [Sitaram Chamarty]
file Makefile Mon Sep 21 06:31:47 -0700 2009 Makefile wraps "git archive" to record "git des... [Sitaram Chamarty]
file README.mkd Thu Jan 14 21:10:07 -0800 2010 mention NAME-based restrictions in README [Sitaram Chamarty]
directory conf/ Wed Jan 27 03:18:56 -0800 2010 document the "include" mechanism [Sitaram Chamarty]
directory doc/ Sun Jan 31 21:14:48 -0800 2010 Merge remote branch 'origin/pu' [Sitaram Chamarty]
directory src/ Wed Jan 27 06:12:58 -0800 2010 easy install: two rc file update bugs fixed Th... [Sitaram Chamarty]
README.mkd

gitolite

[Update 2009-10-28: apart from all the nifty new features, there's now an "easy install" script in the src directory. This script can be used to install as well as upgrade a gitolite install. Please see the INSTALL document for details]


Gitolite is a rewrite of gitosis, with a completely different config file that allows (at last!) access control down to the branch level, including specifying who can and cannot rewind a given branch.

In this document:

  • what
  • why
  • extra features
  • security
  • contact and license

what

Gitolite allows a server to host many git repositories and provide access to many developers, without having to give them real userids on the server. The essential magic in doing this is ssh's pubkey access and the authorized_keys file, and the inspiration was an older program called gitosis.

Gitolite can restrict who can read from (clone/fetch) or write to (push) a repository. It can also restrict who can push to what branch or tag, which is very important in a corporate environment. Gitolite can be installed without requiring root permissions, and with no additional software than git itself and perl. It also has several other neat features described below and elsewhere in the doc/ directory.

why

I have been using gitosis for a while, and have learnt a lot from it. But in a typical $DAYJOB setting, there are some issues:

  • it's not always Linux; you can't just "urpmi gitosis" (or yum or apt-get) and be done
  • often, "python-setuptools" isn't installed (and on a Solaris9 I was trying to help remotely, we never did manage to install it eventually)
  • you don't have root access, or the ability to add users (this is also true for people who have just one userid on a hosting provider)
  • the most requested feature (see below) had to be written anyway

All of this pointed to a rewrite. In perl, naturally :-)

extra features

The most important feature I needed was per-branch permissions. This is pretty much mandatory in a corporate environment, and is almost the single reason I started thinking about rolling my own gitosis in the first place.

It's not just "read-only" versus "read-write". Rewinding a branch (aka "non fast forward push") is potentially dangerous, but sometimes needed. So is deleting a branch (which is really just an extreme form of rewind). I needed something in between allowing anyone to do it (the default) and disabling it completely (receive.denyNonFastForwards or receive.denyDeletes).

Here're some more features. All of them, and more, are documented in detail here.

  • simpler, yet far more powerful, config file syntax, including specifying gitweb/daemon access. You'll need this power if you manage lots of users+repos+combinations of access
  • apart from branch-name based restrictions, you can also restrict by file/dir name changed (i.e., output of git diff --name-only)
  • config file syntax gets checked upfront, and much more thoroughly
  • if your requirements are still too complex, you can split up the config file and delegate authority over parts of it
  • easier to specify gitweb owner, description and gitweb/daemon access
  • easier to sync gitweb (http) authorisation with gitolite's access config
  • more comprehensive logging [aka: management does not think "blame" is just a synonym for "annotate" :-)]
  • "personal namespace" prefix for each dev
  • migration guide and simple converter for gitosis conf file
  • "exclude" (or "deny") rights at the branch/tag level

security

Due to the environment in which this was created and the need it fills, I consider this a "security" program, albeit a very modest one. The code is very small and easily reviewable -- the 2 programs that actually control access when a user logs in total about 220 lines of code (about 90 lines according to "sloccount").

For the first person to find a security hole in it, defined as allowing a normal user (not the gitolite admin) to read a repo, or write/rewind a ref, that the config file says he shouldn't, and caused by a bug in code that is in the "master" branch, (not in the other branches, or the configuration file or in Unix, perl, shell, etc.)... well I can't afford 1000 USD rewards like djb, so you'll have to settle for 1000 INR (Indian Rupees) as a "token" prize :-)


contact and license

Gitolite is released under GPL v2. See COPYING for details.

sitaramc@gmail.com

Blog | Support | Training | Contact | API | Status | Twitter | Help | Security
© 2010 GitHub Inc. All rights reserved. | Terms of Service | Privacy Policy
Powered by the Dedicated Servers and
Cloud Computing of Rackspace Hosting®
Dedicated Server