non-core features shipped with gitolite


Important Notes on "non-core" features:

  1. The "non-core" gitolite page is the starting point for all information about ... non-core gitolite :)

  2. This page decribes many of the non-core features that come with gitolite. If a non-core feature is shipped with gitolite, but information about it is not found in this page, it can be found within the source code; please look there.

    Commands, however, have some extra magic, which is not available to the other types of non-core programs:

    • Running the command with a single -h option (i.e., gitolite <command> -h or ssh git@host <command> -h), will display a suitable message. Please report a bug to me if one of them doesn't.

    • Running 'help', (either as gitolite help on the server, or ssh git@host help remotely), will give you a list of commands you are allowed to run.

  3. Non-core code is meant to be localised for your site if you don't like what the shipped version does. You can even maintain it within your gitolite-admin repo if you wish.

commands

This is a list of commands that are available in gitolite, with brief descriptions and, if available, a link to more detailed information. Note that in most cases running it with -h will give you enough to work with.

Also note that not all of these commands are available remotely.

(The more common/important commands are in bold).

syntactic sugar

The following "sugar" programs are available:

triggers

Here's a list of features that are enabled by triggers, or a combination of a trigger and something else, like a command.

In addition, the following post-compile trigger scripts are enabled by default, so are included here only for completeness and in case you wish to disable them:

VREFs

VREFs are a complex topic and have their own page with lots more details. However, here's a list of VREFs shipped with gitolite:

details on some non-core programs

These non-core programs needed more detail than could be provided in the source code, but did not fit anywhere else neatly enough.

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.

Gerrit Code Review can do that, but that is because they have their own git (as well as their own sshd, and so on). If code review is part of your access control decision, you really should consider Gerrit anyway.

The standard answer you get when you ask is "use separate repos" (where one contains all the branches, and one contains a subset of the branches). This is nice in theory but in practice, when people are potentially pushing to both repos, you need to figure out how to keep them in sync.

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 ENABLE list 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 # first, a deny rule that allows no access to secret-branch - secret-branch = @all

    # 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: