gitolite/doc/non-core.mkd

non-core programs shipped with gitolite

---

TOC

---

commands

A list of these commands can be obtained by running gitolite help on the server. A different (and probably much smaller) list can be obtained by a remote user running ssh git@host help.

All the commands that ship with gitolite will respond to -h; please report a bug to me if they don't.

A particularly interesting command is the 'sudo' command, which allows an admin to run any remote command as some other user (though not the other way round!)

Here's a list of some commands where additional information is available elsewhere:

• 'info' -- documented [here][info]
• 'mirror' -- documented [here][sync]
• 'perms' -- get/set the gl-perms file; see [perms][] for more
• 'sskm' -- self-service key management, see [sskm][] for more

syntactic sugar

The following "sugar" programs are available:

• Continuation-lines -- allow the use of C-style backslash escaped continuation lines in the conf file. I don't like it but some people do, and now I can support them without bulking up the "core" conf parser!

• Keysubdirs-as-groups -- someone wanted the sub-directory name (of "keydir/") in which the pubkey was placed to be a group to which the user automatically belonged. A very unusual requirement, and one which would never have seen the light of day in g2, but in g3 it's easy, and doesn't affect anyone else!

  (Note: the last component of the directory path is used if there are more than one level between "keydir/" and the actual file).

triggers

Most triggers need to be enabled by adding or uncommenting an appropriate line in the [rc][] file. There are enough examples in there for the syntax to not need explanation.

Some features need to be enabled in more than one trigger. Mirroring is probably the best example -- it needs to hook into the INPUT, PRE_GIT, and the POST_GIT triggers to work.

In general, the source code for each trigger will tell you what it is doing and which trigger list you should add it to. Please note that there are two types of [triggers][]; the perl triggers usually have subroutine names that reflect what trigger sections they should go into. (Using mirroring as an example again, the Mirroring.pm perl module has sub's named 'input', 'pre_git', and 'post_git').

Please report a bug to me if you could not find the information you wanted on any specific trigger.

Here's a list of some triggers where additional information is available elsewhere:

• Shell -- see "giving shell access to gitolite users" in [this][sts] page.
• Mirroring -- see [doc/mirroring.mkd][mirroring]
• partial-copy -- this has its own section later in this page.

VREFs

VREFs have their [own page][vref].

special cases

#partial-copy partial-copy: selective read control for branches

Git (and therefore gitolite) cannot do selective read control -- allowing someone to read branch A but not branch B. It's the entire repo or nothing.

[Side note: Gerrit Code Review can do that, but that is because they have their own git stack (and their own sshd, and so on) all in one big Java program. Gerrit is really useful if you want code review to be part of the access control decision]

Gitolite can now help you do this. Note that this is only for branches; you can't do this for files and directories.

Here's how:

1. enable 'partial-copy' in the PRE_GIT section in the rc file.

2. for each repo "foo" which has secret branches that a certain set of developers (we'll use a group called @temp-emp as an example) are not supposed to see, do this:

   repo foo
       # rules should allow @temp-emp NO ACCESS
   
   repo foo-partialcopy-1
       -   secret-branch               =   @temp-emp
   
       # other rules; see notes below
   
       -   VREF/partial-copy           =   @all
       config gitolite.partialCopyOf   =   foo
   

   IMPORTANT NOTES:

   • if you're using other VREFs, make sure this one is placed at the end, after all the others.

   • remember that any change allowed to be made to the partial-copy repo will propagate to the main repo so make sure you use other rules to restrict pushes to other branches and tags as needed.

And that should be it. Please test it and let me know if it doesn't work!

WARNINGS:

• If you change the config to disallow something that used to be allowed, you should delete the partial repo on the server and then run gitolite compile; gitolite trigger POST_COMPILE to let it build again.

• Not tested with smart http; probably won't work.

• Also not tested with mirroring, or with wild card repos.