gitolite/doc/g2incompat.mkd

# #g2incompat incompatibility with g2

This page expands on some incompatibilities that were only briefly mentioned
in the [migration][g2migr] page.

## #g2i-name NAME rules

1.  NAME/ rules must be changed to VREF/NAME/

2.  Fallthru on all VREFs is "success" now, so any NAME/ rules you have
    **MUST** change the ruleset in some way to maintain the same restrictions.
    The simplest is to add the following line to the end of each repo's rule
    list:

        -   VREF/NAME/       =   @all

## #g2i-subconf subconf command in admin repo

(This is also affected by the previous issue, 'NAME rules'; please read that
as well).

If you're using delegation in your admin conf setup, please add the following
lines to the end of the gitolite-admin rules in your conf/gitolite.conf file:

    repo gitolite-admin
        -   VREF/NAME/       =   @all

    subconf "fragments/*.conf"

The first part compensates for fallthru now being a success when processing
[VREF][vref] rules (NAME rules are just one specific VREF).  Although,
**ideally**, you should change your ruleset so that you no longer require that
line.  As the [vref documentation][vref] says:

>   **Virtual refs are best used as additional "deny" rules**, performing
>   extra checks that core gitolite cannot.

The second part explicitly says when and where to include the subconf files.
(Before subconf was invented, this used to happen implicitly at the end of the
main conf file, and was hardcoded to that specific glob.)

## #g2i-gl-time gl-time for performance measurement

If you've been using gl-time for performance measurement, there's a much
better system available now.

gl-time used to only log elapsed time.  The new 'CpuTime' trigger module
shipped with gitolite, if enabled in the rc file, can also report CPU times
using perl's 'times()' function.  See comments within that file and in the
default rc file that contain the word "cpu", for more details.

Further, you can copy that module with a different name, add your own
functionality, and invoke *that* from the rc file instead.

## #g2i-mirroring changes in mirroring setup

There are several changes with regard to mirroring:

  * There is no 'post-receive' hook to be installed.  Mirroring is handled by
    g3's [triggers][] mechanism.  Gitolite triggers are enabled by adding (or
    uncommenting, in this case) appropriate lines in the rc file.

  * The `GL_HOSTNAME` variable is now `HOSTNAME`.  (Note that the rc file
    syntax itself has changed quite a bit; to be accurate, HOSTNAME is not a
    variable but a hash key with an associated value).

  * The `GL_GITCONFIG_KEYS` variable is now `GIT_CONFIG_KEYS`, **but** you no
    longer need to set it to anything for mirroring to work.

  * The `gl-tool` program does not exist anymore.  Adding keys for peer
    servers is done just like adding user keys, except that the pubkey file
    name must start with `server-`.  For example, to add a peer host called
    frodo, you will acquire its pubkey and add it as `server-frodo.pub`.

  * The config variables are quite different now.  The main ones now look like
    this:

        option mirror.master        =   sam
        option mirror.slaves        =   frodo gollum

    The redirectOK looks like this:

        option mirror.redirectOK    =   frodo

    The special value "true" to say that all slaves are trusted is now "all":

        option mirror.redirectOK    =   all

  * There are no more mirroring "keys", (lists of servers named in config keys
    like 'gitolite.mirror.nightly', etc).  You can certainly add lines like

        option mirror.nightly       =   merry pippin

    but they will not be processed by gitolite.  Your cron jobs should use
    `gitolite git-config` to query this variable, grab the list of peers, and
    run `gitolite mirror` on each of them.

  * The external command to resync mirrors is 'mirror', run just like any
    other [command][commands].  In particular, you can run `gitolite mirror
    -h` to get help.  It cannot be run from a slave to ask a master to push
    (unlike in the old system) but what's more convenient is that any user who
    has any access to the master can run it remotely (if you allow it) to
    invoke a push.