master TOC | main page | single-page | license | New: Gitolite Essentials book
This is for gitolite "g3"; for older (v2.x) documentation click here
Note: The old gitolite (v1.x, v2.x) used to tie itself into knots dealing with gitweb and daemon. One of the goals of g3 was to get out of that game, which your author does not play anyway. This means statements like "...special user called 'gitweb'..." really apply to the non-core programs that gitolite ships with, not to "core" gitolite, and any or all of this functionality can be disabled by commenting out certain lines in the rc file.
Also, note that gitolite does not install or configure gitweb/git-daemon -- that is a one-time setup you must do separately.
The following repos are deemed to be readable by gitweb:
any repos containing one or more of the following types of lines: (actually, any config variable starting with
config gitweb.owner = owner name config gitweb.description = some description config gitweb.category = some category
Side note: the following shorter forms are available as syntactic sugar for the above longer forms:
owner = owner name desc = some description category = some category
The list of gitweb-readable repos is written to a file whose name is given by the rc file variable
GITWEB_PROJECTS_LIST. The default value of this variable, if it is not specified or empty, is
In addition, each of the config variables described above is written to the repo to which it pertains, so that gitweb can use them.
Gitweb (or cgit, redmine, etc.) typically runs under a different userid, and the default permissions that gitolite sets make them unreadable.
See the section on the
UMASK variable in the documentation for the rc file.
Gitweb has a feature whereby it will call a (perl) function that you supply, passing it the full path to the repo being accessed. If the remote user is authenticated, the username will be available, so your function can take those two pieces of information and return true or false to allow or deny the repository access.
If you want to use gitolite's access rules in making this determination, you will first have to ensure that the HTTP username (i.e., the username known to apache/gitweb) is the same as the gitolite username. If you're using gitolite's http mode, this is probably already true, but if you're using the more widely used ssh mode, you'll have to make sure they match.
You then need to add this code to your gitweb.conf.
Any repo readable by the special user
daemon is deemed to be readable by git-daemon. For each of these repos, an empty file called
git-daemon-export-ok is created in the repository (i.e., the
repo.git directory inside
Setting descriptions en-masse usually does not make sense, but you can certainly do things like
repo @all R = gitweb daemon
assuming you have other means of setting 'gitweb.description' and 'gitweb.owner'.
Also see this for a twist on that.