README.txt -> README.md + clean up

Not following through on instructions to remove a repo, per [1], is not
sufficient.  Even if you did just the first step, the repo should  no
longer be accessible.  See [2] for discussion.

As a bonus, we get rid of one pesky warning that always confused people.
(In hindsight -- this confusion itself should have been a warning that
something is wrong and needed fixing!)

[1]: http://sitaramc.github.com/gitolite/repos.html
[2]: http://groups.google.com/group/gitolite/browse_thread/thread/a3d4c3e917056abb

CHANGELOG

@@ -1,3 +1,18 @@
+2012-12-29  v3.3    bug fix: gl-perms propagation to slaves broke sometime
+                    after v3.2 (so if you're only picking up tagged releases
+                    you're OK)
+
+                    the "D" command now allows rm/unlock to be totally
+                    disabled
+
+                    new trigger: update-gitweb-daemon-from-options; another
+                    way to update gitweb and daemon access lists
+
+                    new 'create' command for explicit wild repo creation, and
+                    new AutoCreate trigger to control auto-creation
+
+                    allow simple macros in conf file
+
 2012-11-14  v3.2    major efficiency boost for large setups
 
                     optional support for multi-line pubkeys; see

README.md

@@ -0,0 +1,359 @@
+Github-users: click the 'wiki' link before sending me anything via github.
+
+Existing users: this is gitolite v3.x.  If you are upgrading from v2.x this
+file will not suffice; you *must* check the online docs (see below for URL).
+
+------------------------------------------------------------------------
+
+
+This file contains BASIC DOCUMENTATION ONLY.
+
+* It is suitable for a fresh, ssh-based, installation of gitolite and basic
+  usage of its most important features.
+* It is NOT meant to be exhaustive or detailed.
+
+The COMPLETE DOCUMENTATION is at:
+
+	http://sitaramc.github.com/gitolite/master-toc.html
+
+Please go there for what/why/how, concepts, background, troubleshooting, more
+details on what is covered here, or advanced features not covered here.
+
+------------------------------------------------------------------------
+
+
+BASIC DOCUMENTATION FOR GITOLITE
+================================
+
+This file contains the following sections:
+
+* INSTALLATION AND SETUP
+* ADDING USERS AND REPOS
+* HELP FOR YOUR USERS
+* BASIC SYNTAX
+* ACCESS RULES
+* GROUPS
+* COMMANDS
+* THE 'rc' FILE
+* GIT-CONFIG
+* GIT-DAEMON
+* GITWEB
+* CONTACT AND SUPPORT
+* LICENSE
+
+------------------------------------------------------------------------
+
+
+INSTALLATION AND SETUP
+----------------------
+
+Server requirements:
+
+* any unix system
+* sh
+* git 1.6.6+
+* perl 5.8.8+
+* openssh 5.0+
+* a dedicated userid to host the repos (in this document, we assume it
+	is 'git'), with shell access ONLY by 'su - git' from some other userid
+	on the same server.
+
+Steps to install:
+
+* login as 'git' as described above
+* make sure ~/.ssh/authorized_keys is empty or non-existent
+* make sure your ssh public key from your workstation is available at $HOME/YourName.pub
+* run the following commands:
+
+		git clone git://github.com/sitaramc/gitolite
+		mkdir -p $HOME/bin
+		gitolite/install -to $HOME/bin
+		gitolite setup -pk YourName.pub
+
+	If the last command doesn't run perhaps 'bin' in not in your 'PATH'.
+	You can either add it, or just run:
+
+		$HOME/bin/gitolite setup -pk YourName.pub
+
+
+ADDING USERS AND REPOS
+----------------------
+
+Do NOT add new repos or users manually on the server.  Gitolite users,
+repos, and access rules are maintained by making changes to a special repo
+called 'gitolite-admin' and pushing those changes to the server.
+
+----
+
+To administer your gitolite installation, start by doing this on your
+workstation (if you have not already done so):
+
+	git clone git@host:gitolite-admin
+
+**NOTE**: if you are asked for a password, something has gone wrong.
+
+Now if you 'cd gitolite-admin', you will see two subdirectories in it:
+'conf' and 'keydir'.
+
+To add new users alice, bob, and carol, obtain their public keys and add
+them to 'keydir' as alice.pub, bob.pub, and carol.pub respectively.
+
+To add a new repo 'foo' and give different levels of access to these
+users, edit the file 'conf/gitolite.conf' and add lines like this:
+
+	repo foo
+		RW+         =   alice
+		RW          =   bob
+		R           =   carol
+
+See the 'ACCESS RULES' section later for more details.
+
+Once you have made these changes, do something like this:
+
+	git add conf
+	git add keydir
+	git commit -m 'added foo, gave access to alice, bob, carol'
+	git push
+
+When the push completes, gitolite will add the new users to
+~/.ssh/authorized_keys on the server, as well as create a new, empty, repo
+called 'foo'.
+
+
+HELP FOR YOUR USERS
+-------------------
+
+Once a user has sent you their public key and you have added them as
+specified above and given them access, you have to tell them what URL to
+access their repos at.  This is usually 'git clone git@host:reponame'; see
+man git-clone for other forms.
+
+**NOTE**: again, if they are asked for a password, something is wrong.
+
+If they need to know what repos they have access to, they just have to run
+'ssh git@host info'; see 'COMMANDS' section later for more on this.
+
+
+BASIC SYNTAX
+------------
+
+The basic syntax of the conf file is very simple.
+
+* Everything is space separated; there are no commas, semicolons, etc.,
+	in the syntax.
+* Comments are in the usual perl/shell style.
+* User and repo names are as simple as possible; they must start with an
+	alphanumeric, but after that they can also contain '.', '_', or '-'.
+
+	Usernames can optionally be followed by an '@' and a domainname
+	containing at least one '.'; this allows you to use an email address
+	as someone's username.
+
+	Reponames can contain '/' characters; this allows you to put your
+	repos in a tree-structure for convenience.
+* There are no continuation lines.
+
+
+ACCESS RULES
+------------
+
+This section is mostly 'by example'.
+
+Gitolite's access rules are very powerful.  The simplest use was already
+shown above.  Here is a slightly more detailed example:
+
+	repo foo
+		RW+                     =   alice
+		-   master              =   bob
+		-   refs/tags/v[0-9]    =   bob
+		RW                      =   bob
+		RW  refs/tags/v[0-9]    =   carol
+		R                       =   dave
+
+For clones and fetches, as long as the user is listed with an R, RW
+or RW+ in at least one rule, he is allowed to read the repo.
+
+For pushes, rules are processed in sequence until a rule is found
+where the user, the permission (see note 1), and the refex (note 2)
+*all* match.  At that point, if the permission on the matched rule
+was '-', the push is denied, otherwise it is allowed.  If no rule
+matches, the push is denied.
+
+Note 1: permission matching:
+
+* a permission of RW matches only a fast-forward push or create
+* a permission of RW+ matches any type of push
+* a permission of '-' matches any type of push
+
+Note 2: refex matching:
+(refex = optional regex to match the ref being pushed)
+
+* an empty refex is treated as 'refs/.*'
+* a refex that does not start with 'refs/' is prefixed with 'refs/heads/'
+* finally, a '^' is prefixed
+* the ref being pushed is matched against this resulting refex
+
+With all that background, here's what the example rules say:
+
+* alice can do anything to any branch or tag -- create, push, delete, rewind/overwrite etc.
+* bob can create or fast-forward push any branch whose name does
+	not start with 'master' and create any tag whose name does not
+	start with 'v'+digit.
+* carol can create tags whose names start with 'v'+digit.
+* dave can clone/fetch.
+
+
+GROUPS
+------
+
+Gitolite allows you to group users or repos for convenience.  Here's an
+example that creates two groups of users:
+
+	@staff      =   alice bob carol
+	@interns    =   ashok
+
+	repo secret
+		RW      =   @staff
+
+	repo foss
+		RW+     =   @staff
+		RW      =   @interns
+
+Group lists accumulate.  The following two lines have the same effect as
+the earlier definition of @staff above:
+
+	@staff      =   alice bob
+	@staff      =   carol
+
+You can also use group names in other group names:
+
+	@all-devs   =   @staff @interns
+
+Finally, @all is a special group name that is often convenient to use if
+you really mean 'all repos' or 'all users'.
+
+
+COMMANDS
+--------
+
+Users can run certain commands remotely, using ssh.  For example:
+
+	ssh git@host help
+
+prints a list of available commands.
+
+The most commonly used command is 'info'.  All commands respond to a
+single argument of '-h' with suitable information.
+
+If you have shell on the server, you have a lot more commands available to
+you; try running 'gitolite help'.
+
+
+THE 'rc' FILE
+--------------
+
+Some of the instructions below may require you to edit the rc file
+(~/.gitolite.rc on the server).
+
+The rc file is perl code, but you do NOT need to know perl to edit it.
+Just mind the commas, use single quotes unless you know what you're doing,
+and make sure the brackets and braces stay matched up.
+
+
+GIT-CONFIG
+----------
+
+Gitolite lets you set git-config values for individual repos without
+having to log on to the server and run 'git config' commands:
+
+	repo foo
+		config hooks.mailinglist = foo-commits@example.tld
+		config hooks.emailprefix = '[foo] '
+		config foo.bar = ''
+		config foo.baz =
+
+**WARNING**
+
+The last syntax shown above is the *only* way to *delete* a config
+variable once you have added it.  Merely removing it from the conf
+file will *not* delete it from the repo.git/config file.
+
+**SECURITY NOTE**
+
+Some git-config keys allow arbitrary code to be run on the server.
+
+If all of your gitolite admins already have shell access to the server
+account hosting it, you can edit the rc file (~/.gitolite.rc) on the
+server, and change the GIT_CONFIG_KEYS line to look like this:
+
+	GIT_CONFIG_KEYS     =>  '.*',
+
+Otherwise, give it a space-separated list of regular expressions that
+define what git-config keys are allowed.  For example, this one allows
+only variables whose names start with 'gitweb' or with 'gc' to be
+defined:
+
+	GIT_CONFIG_KEYS     =>  'gitweb\..* gc\..*',
+
+
+GIT-DAEMON
+----------
+
+Gitolite creates the 'git-daemon-export-ok' file for any repo that is
+readable by a special user called 'daemon', like so:
+
+	repo foo
+		R   =   daemon
+
+
+GITWEB
+------
+
+Any repo that is readable by a special user called 'gitweb' will be added
+to the projects.list file.
+
+	repo foo
+		R   =   gitweb
+
+Or you can set one or more of the following config variables instead:
+
+	repo foo
+		config gitweb.owner         =   some person's name
+		config gitweb.description   =   some description
+		config gitweb.category      =   some category
+
+**NOTE**
+
+You will probably need to change the UMASK in the rc file from the
+default (0077) to 0027 and add whatever user your gitweb is running as
+to the 'git' group.  After that, you need to run a one-time 'chmod -R'
+on the already created files and directories.
+
+------------------------------------------------------------------------
+
+
+CONTACT AND SUPPORT
+-------------------
+
+Mailing list for support and general discussion:
+	gitolite@googlegroups.com
+	subscribe address: gitolite+subscribe@googlegroups.com
+
+Mailing list for announcements and notices:
+	subscribe address: gitolite-announce+subscribe@googlegroups.com
+
+IRC: #git and #gitolite on freenode.  Note that I live in India (UTC+0530
+time zone).
+
+Author: sitaramc@gmail.com, but please DO NOT use this for general support
+questions.  Subscribe to the list and ask there instead.
+
+
+LICENSE
+-------
+
+The gitolite *code* is released under GPL v2.  See COPYING for details.
+
+This documentation, which is part of the source code repository, is
+provided under a Creative Commons Attribution-ShareAlike 3.0 Unported
+License -- see http://creativecommons.org/licenses/by-sa/3.0/

README.txt

@@ -1,373 +0,0 @@
-Github-users: click the 'wiki' link before sending me anything via github.
-
-Existing users: this is gitolite v3.x.  If you are upgrading from v2.x this
-file will not suffice; you *must* check the online docs (see below for URL).
-
-------------------------------------------------------------------------
-
-
-This file contains BASIC DOCUMENTATION ONLY.
-
-  * It is suitable for a fresh, ssh-based, installation of gitolite and basic
-    usage of its most important features.
-
-  * It is NOT meant to be exhaustive or detailed.
-
-The COMPLETE DOCUMENTATION is at:
-
-    http://sitaramc.github.com/gitolite/master-toc.html
-
-Please go there for what/why/how, concepts, background, troubleshooting, more
-details on what is covered here, or advanced features not covered here.
-
-------------------------------------------------------------------------
-
-
-BASIC DOCUMENTATION FOR GITOLITE
-================================
-
-This file contains the following sections:
-
-    INSTALLATION AND SETUP
-    ADDING USERS AND REPOS
-    HELP FOR YOUR USERS
-    BASIC SYNTAX
-    ACCESS RULES
-    GROUPS
-    COMMANDS
-    THE 'rc' FILE
-    GIT-CONFIG
-    GIT-DAEMON
-    GITWEB
-
-    CONTACT AND SUPPORT
-    LICENSE
-
-------------------------------------------------------------------------
-
-
-INSTALLATION AND SETUP
-----------------------
-
-    Server requirements:
-
-      * any unix system
-      * sh
-      * git 1.6.6+
-      * perl 5.8.8+
-      * openssh 5.0+
-      * a dedicated userid to host the repos (in this document, we assume it
-        is 'git'), with shell access ONLY by 'su - git' from some other userid
-        on the same server.
-
-    Steps to install:
-
-      * login as 'git' as described above
-
-      * make sure ~/.ssh/authorized_keys is empty or non-existent
-
-      * make sure your ssh public key from your workstation is available at
-        $HOME/YourName.pub
-
-      * run the following commands:
-
-            git clone git://github.com/sitaramc/gitolite
-            mkdir -p $HOME/bin
-            gitolite/install -to $HOME/bin
-            gitolite setup -pk YourName.pub
-
-        If the last command doesn't run perhaps 'bin' in not in your 'PATH'.
-        You can either add it, or just run:
-
-            $HOME/bin/gitolite setup -pk YourName.pub
-
-
-ADDING USERS AND REPOS
-----------------------
-
-    Do NOT add new repos or users manually on the server.  Gitolite users,
-    repos, and access rules are maintained by making changes to a special repo
-    called 'gitolite-admin' and pushing those changes to the server.
-
-    ----
-
-    To administer your gitolite installation, start by doing this on your
-    workstation (if you have not already done so):
-
-        git clone git@host:gitolite-admin
-
-    **NOTE**: if you are asked for a password, something has gone wrong.
-
-    Now if you 'cd gitolite-admin', you will see two subdirectories in it:
-    'conf' and 'keydir'.
-
-    To add new users alice, bob, and carol, obtain their public keys and add
-    them to 'keydir' as alice.pub, bob.pub, and carol.pub respectively.
-
-    To add a new repo 'foo' and give different levels of access to these
-    users, edit the file 'conf/gitolite.conf' and add lines like this:
-
-        repo foo
-            RW+         =   alice
-            RW          =   bob
-            R           =   carol
-
-    See the 'ACCESS RULES' section later for more details.
-
-    Once you have made these changes, do something like this:
-
-        git add conf
-        git add keydir
-        git commit -m 'added foo, gave access to alice, bob, carol'
-        git push
-
-    When the push completes, gitolite will add the new users to
-    ~/.ssh/authorized_keys on the server, as well as create a new, empty, repo
-    called 'foo'.
-
-
-HELP FOR YOUR USERS
--------------------
-
-    Once a user has sent you their public key and you have added them as
-    specified above and given them access, you have to tell them what URL to
-    access their repos at.  This is usually 'git clone git@host:reponame'; see
-    man git-clone for other forms.
-
-    **NOTE**: again, if they are asked for a password, something is wrong.
-
-    If they need to know what repos they have access to, they just have to run
-    'ssh git@host info'; see 'COMMANDS' section later for more on this.
-
-
-BASIC SYNTAX
-------------
-
-    The basic syntax of the conf file is very simple.
-
-      * Everything is space separated; there are no commas, semicolons, etc.,
-        in the syntax.
-
-      * Comments are in the usual perl/shell style.
-
-      * User and repo names are as simple as possible; they must start with an
-        alphanumeric, but after that they can also contain '.', '_', or '-'.
-
-        Usernames can optionally be followed by an '@' and a domainname
-        containing at least one '.'; this allows you to use an email address
-        as someone's username.
-
-        Reponames can contain '/' characters; this allows you to put your
-        repos in a tree-structure for convenience.
-
-      * There are no continuation lines.
-
-
-ACCESS RULES
-------------
-
-    This section is mostly 'by example'.
-
-    Gitolite's access rules are very powerful.  The simplest use was already
-    shown above.  Here is a slightly more detailed example:
-
-        repo foo
-            RW+                     =   alice
-            -   master              =   bob
-            -   refs/tags/v[0-9]    =   bob
-            RW                      =   bob
-            RW  refs/tags/v[0-9]    =   carol
-            R                       =   dave
-
-    For clones and fetches, as long as the user is listed with an R, RW
-    or RW+ in at least one rule, he is allowed to read the repo.
-
-    For pushes, rules are processed in sequence until a rule is found
-    where the user, the permission (see note 1), and the refex (note 2)
-    *all* match.  At that point, if the permission on the matched rule
-    was '-', the push is denied, otherwise it is allowed.  If no rule
-    matches, the push is denied.
-
-    Note 1: permission matching:
-
-      * a permission of RW matches only a fast-forward push or create
-      * a permission of RW+ matches any type of push
-      * a permission of '-' matches any type of push
-
-    Note 2: refex matching:
-    (refex = optional regex to match the ref being pushed)
-
-      * an empty refex is treated as 'refs/.*'
-      * a refex that does not start with 'refs/' is prefixed with 'refs/heads/'
-      * finally, a '^' is prefixed
-      * the ref being pushed is matched against this resulting refex
-
-    With all that background, here's what the example rules say:
-
-      * alice can do anything to any branch or tag -- create, push,
-        delete, rewind/overwrite etc.
-
-      * bob can create or fast-forward push any branch whose name does
-        not start with 'master' and create any tag whose name does not
-        start with 'v'+digit.
-
-      * carol can create tags whose names start with 'v'+digit.
-
-      * dave can clone/fetch.
-
-
-GROUPS
-------
-
-    Gitolite allows you to group users or repos for convenience.  Here's an
-    example that creates two groups of users:
-
-        @staff      =   alice bob carol
-        @interns    =   ashok
-
-        repo secret
-            RW      =   @staff
-
-        repo foss
-            RW+     =   @staff
-            RW      =   @interns
-
-    Group lists accumulate.  The following two lines have the same effect as
-    the earlier definition of @staff above:
-
-        @staff      =   alice bob
-        @staff      =   carol
-
-    You can also use group names in other group names:
-
-        @all-devs   =   @staff @interns
-
-    Finally, @all is a special group name that is often convenient to use if
-    you really mean 'all repos' or 'all users'.
-
-
-COMMANDS
---------
-
-    Users can run certain commands remotely, using ssh.  For example:
-
-        ssh git@host help
-
-    prints a list of available commands.
-
-    The most commonly used command is 'info'.  All commands respond to a
-    single argument of '-h' with suitable information.
-
-    If you have shell on the server, you have a lot more commands available to
-    you; try running 'gitolite help'.
-
-
-THE 'rc' FILE
---------------
-
-    Some of the instructions below may require you to edit the rc file
-    (~/.gitolite.rc on the server).
-
-    The rc file is perl code, but you do NOT need to know perl to edit it.
-    Just mind the commas, use single quotes unless you know what you're doing,
-    and make sure the brackets and braces stay matched up.
-
-
-GIT-CONFIG
-----------
-
-    Gitolite lets you set git-config values for individual repos without
-    having to log on to the server and run 'git config' commands:
-
-        repo foo
-            config hooks.mailinglist = foo-commits@example.tld
-            config hooks.emailprefix = '[foo] '
-            config foo.bar = ''
-            config foo.baz =
-
-    **WARNING**
-
-        The last syntax shown above is the *only* way to *delete* a config
-        variable once you have added it.  Merely removing it from the conf
-        file will *not* delete it from the repo.git/config file.
-
-    **SECURITY NOTE**
-
-        Some git-config keys allow arbitrary code to be run on the server.
-
-        If all of your gitolite admins already have shell access to the server
-        account hosting it, you can edit the rc file (~/.gitolite.rc) on the
-        server, and change the GIT_CONFIG_KEYS line to look like this:
-
-            GIT_CONFIG_KEYS     =>  '.*',
-
-        Otherwise, give it a space-separated list of regular expressions that
-        define what git-config keys are allowed.  For example, this one allows
-        only variables whose names start with 'gitweb' or with 'gc' to be
-        defined:
-
-            GIT_CONFIG_KEYS     =>  'gitweb\..* gc\..*',
-
-
-GIT-DAEMON
-----------
-
-    Gitolite creates the 'git-daemon-export-ok' file for any repo that is
-    readable by a special user called 'daemon', like so:
-
-        repo foo
-            R   =   daemon
-
-
-GITWEB
-------
-
-    Any repo that is readable by a special user called 'gitweb' will be added
-    to the projects.list file.
-
-        repo foo
-            R   =   gitweb
-
-    Or you can set one or more of the following config variables instead:
-
-        repo foo
-            config gitweb.owner         =   some person's name
-            config gitweb.description   =   some description
-            config gitweb.category      =   some category
-
-    **NOTE**
-
-        You will probably need to change the UMASK in the rc file from the
-        default (0077) to 0027 and add whatever user your gitweb is running as
-        to the 'git' group.  After that, you need to run a one-time 'chmod -R'
-        on the already created files and directories.
-
-
-------------------------------------------------------------------------
-
-
-CONTACT AND SUPPORT
--------------------
-
-    Mailing list for support and general discussion:
-        gitolite@googlegroups.com
-        subscribe address: gitolite+subscribe@googlegroups.com
-
-    Mailing list for announcements and notices:
-        subscribe address: gitolite-announce+subscribe@googlegroups.com
-
-    IRC: #git and #gitolite on freenode.  Note that I live in India (UTC+0530
-    time zone).
-
-    Author: sitaramc@gmail.com, but please DO NOT use this for general support
-    questions.  Subscribe to the list and ask there instead.
-
-
-LICENSE
--------
-
-    The gitolite *code* is released under GPL v2.  See COPYING for details.
-
-    This documentation, which is part of the source code repository, is
-    provided under a Creative Commons Attribution-ShareAlike 3.0 Unported
-    License -- see http://creativecommons.org/licenses/by-sa/3.0/

src/commands/git-annex-shell

@@ -1,80 +0,0 @@
-#!/usr/bin/perl
-
-use lib $ENV{GL_LIBDIR};
-use Gitolite::Easy;
-
-# This command requires unrestricted arguments, so instead of adding it to the
-# COMMANDS hash in the usual way, you need to add it like so:
-#   'git-annex-shell' => 'ua',
-# (i.e., the value for the key should be the string 'ua').
-#
-# This requires git-annex version 20111016 or newer. Older versions won't
-# be secure.
-
-use strict;
-use warnings;
-
-# ignore @ARGV and look at the original unmodified command
-my $cmd = $ENV{SSH_ORIGINAL_COMMAND};
-
-# Expect commands like:
-#   git-annex-shell 'configlist' '/~/repo'
-#   git-annex-shell 'sendkey' '/~/repo' 'key'
-# The parameters are always single quoted, and the repo path is always
-# the second parameter.
-# Further parameters are not validated here (see below).
-die "bad git-annex-shell command: $cmd"
-  unless $cmd =~ m#^(git-annex-shell '\w+' ')/\~/([0-9a-zA-Z][0-9a-zA-Z._\@/+-]*)('( .*|))$#;
-my $start = $1;
-my $repo  = $2;
-my $end   = $3;
-die "I dont like some of the characters in $repo\n" unless $repo =~ $Gitolite::Rc::REPONAME_PATT;
-die "I dont like absolute paths in $cmd\n" if $repo =~ /^\//;
-die "I dont like '..' paths in $cmd\n"     if $repo =~ /\.\./;
-
-# Modify $cmd, fixing up the path to the repo to include GL_REPO_BASE.
-my $newcmd = "$start$rc{GL_REPO_BASE}/$repo$end";
-
-# Rather than keeping track of which git-annex-shell commands
-# require write access and which are readonly, we tell it
-# when readonly access is needed.
-if ( can_write($repo) ) {
-} elsif ( can_read($repo) ) {
-    $ENV{GIT_ANNEX_SHELL_READONLY} = 1;
-} else {
-    die "$repo $ENV{GL_USER} DENIED\n";
-}
-# Further limit git-annex-shell to safe commands (avoid it passing
-# unknown commands on to git-shell)
-$ENV{GIT_ANNEX_SHELL_LIMITED} = 1;
-
-# Note that $newcmd does *not* get evaluated by the unix shell.
-# Instead it is passed as a single parameter to git-annex-shell for
-# it to parse and handle the command. This is why we do not need to
-# fully validate $cmd above.
-Gitolite::Common::gl_log( $ENV{SSH_ORIGINAL_COMMAND} );
-exec "git-annex-shell", "-c", $newcmd;
-
-__END__
-
-INSTRUCTIONS... (NEED TO BE VALIDATED BY SOMEONE WHO KNOWS GIT-ANNEX WELL).
-
-based on http://git-annex.branchable.com/tips/using_gitolite_with_git-annex/
-ONLY VARIATIONS FROM THAT PAGE ARE WRITTEN HERE.
-
-requirements:
-
-  * gitolite v3.04+ (whatever version has src/commands/git-annex-shell,
-    because I haven't tagged it yet).
-  * git-annex as per that
-
-setup
-
-  * in COMMANDS hash in the rc file, add an entry like this:
-        'git-annex-shell'   =>  'ua',
-    (there is no GL_ADC_PATH and no "ua" subdirectory here, and nothing to
-    "install"; the command already comes with gitolite)
-
-That should be it; everything else should be as in that page.
-
-Once this is tested I'll move it to 'master'.

src/commands/list-dangling-repos

@@ -4,6 +4,7 @@ use warnings;
 
 use lib $ENV{GL_LIBDIR};
 use Gitolite::Common;
+use Gitolite::Conf::Load;
 
 =for usage
 Usage:  gitolite list-dangling-repos
@@ -40,8 +41,9 @@ for my $pr (keys %phy_repos) {
 # Remove regex matches.
 for my $pr (keys %phy_repos) {
     my $matched = 0;
+    my $pr2 = Gitolite::Conf::Load::generic_name($pr);
     for my $r (keys %repos) {
-        if ($pr =~ /^$r$/) {
+        if ($pr =~ /^$r$/ or $pr2 =~ /^$r$/) {
             $matched = 1;
             next;
         }

src/commands/mirror

@@ -48,7 +48,7 @@ if ( $cmd eq 'push' ) {
     if (-f "gl-creator") {
         # try to propagate the wild repo, including creator name and gl-perms
         my $creator = `cat gl-creator`; chomp($creator);
-        trace(1, `cat gl-perms 2>/dev/null | ssh $host CREATOR=$creator perms -c \\'$repo\\'`);
+        trace(1, `cat gl-perms 2>/dev/null | ssh $host CREATOR=$creator perms -c \\'$repo\\' 2>/dev/null`);
     }
 
     my $errors = 0;

src/commands/perms

@@ -43,23 +43,23 @@ if ( $ARGV[0] eq '-l' ) {
     getperms(@ARGV);    # doesn't return
 }
 
+my $generic_error = "repo does not exist, or you are not authorised";
+
 # auto-create the repo if -c passed and repo doesn't exist
 if ( $ARGV[0] eq '-c' ) {
     shift;
     my $repo = $ARGV[0] or usage();
     _die "invalid repo '$repo'" unless $repo =~ $REPONAME_PATT;
 
-    my $d = "$rc{GL_REPO_BASE}/$repo.git";
-    my $errmsg = "repo already exists or you are not authorised to create it";
-    # use the same message in both places to prevent leaking repo existence info
-    _die $errmsg if -d $d;
+    if (not -d "$rc{GL_REPO_BASE}/$repo.git") {
         my $ret = access( $repo, $ENV{GL_USER}, '^C', 'any' );
-    _die $errmsg if $ret =~ /DENIED/;
+        _die $generic_error if $ret =~ /DENIED/;
 
         require Gitolite::Conf::Store;
         Gitolite::Conf::Store->import;
         new_wild_repo( $repo, $ENV{GL_USER}, 'perms-c' );
         gl_log( 'create', $repo, $ENV{GL_USER}, 'perms-c' );
+    }
 }
 
 my $repo = shift;
@@ -70,7 +70,7 @@ _system( "gitolite", "trigger", "POST_CREATE", $repo, $ENV{GL_USER}, 'perms' );
 
 sub getperms {
     my $repo = shift;
-    _die "sorry you are not authorised" if repo_missing($repo) or creator($repo) ne $ENV{GL_USER};
+    _die $generic_error if repo_missing($repo) or creator($repo) ne $ENV{GL_USER};
     my $pf = "$rc{GL_REPO_BASE}/$repo.git/gl-perms";
 
     print slurp($pf) if -f $pf;
@@ -79,17 +79,20 @@ sub getperms {
 }
 
 sub setperms {
-    _die "sorry you are not authorised" if repo_missing($repo) or creator($repo) ne $ENV{GL_USER};
+    _die $generic_error if repo_missing($repo) or creator($repo) ne $ENV{GL_USER};
     my $pf = "$rc{GL_REPO_BASE}/$repo.git/gl-perms";
 
     if ( not @_ ) {
         # legacy mode; pipe data in
+        print STDERR "'batch' mode started, waiting for input (run with '-h' for details).\n";
+        print STDERR "Please hit Ctrl-C if you did not intend to do this.\n";
         @ARGV = ();
         my @a;
         for (<>) {
             _die "Invalid role '$1'; check the rc file" if /(\S+)/ and not $rc{ROLES}{$1};
             push @a, $_;
         }
+        print STDERR "\n";  # make sure Ctrl-C gets caught
         _print( $pf, @a );
         return;
     }

src/gitolite-shell

@@ -152,11 +152,10 @@ sub parse_soc {
     # after this we should not return; caller expects us to handle it all here
     # and exit out
 
+    _die "suspicious characters loitering about '$soc'" if $soc !~ $REMOTE_COMMAND_PATT;
 
     my @words = split ' ', $soc;
     if ( $rc{COMMANDS}{ $words[0] } ) {
-        _die "suspicious characters loitering about '$soc'"
-          if $rc{COMMANDS}{ $words[0] } ne 'ua' and $soc !~ $REMOTE_COMMAND_PATT;
         trace( 2, "gitolite command", $soc );
         _system( "gitolite", @words );
         exit 0;

src/lib/Gitolite/Conf/Load.pm

@@ -246,7 +246,7 @@ sub load_1 {
     }
 
     if ( -f "gl-conf" ) {
-        _warn "split conf not set, gl-conf present for '$repo'" if not $split_conf{$repo};
+        return if not $split_conf{$repo};
 
         my $cc = "./gl-conf";
         _die "parse '$cc' failed: " . ( $! or $@ ) unless do $cc;
@@ -386,6 +386,8 @@ sub user_roles {
     for (@roles) {
         # READERS u3 u4 @g1
         s/^\s+//; s/ +$//; s/=/ /; s/\s+/ /g; s/^\@//;
+        next if /^#/;
+        next unless /\S/;
         my ( $role, @members ) = split;
         # role = READERS, members = u3, u4, @g1
         if ( $role ne 'CREATOR' and not $rc{ROLES}{$role} ) {

t/sequence.t

@@ -100,7 +100,7 @@ try "
     # auto-create using perms fail
     echo READERS u5 | glt perms u4 -c foo/u4/baz
         !/Initialized empty Git repository in .*/foo/u4/baz.git/
-        /FATAL: repo already exists or you are not authorised to create it/
+        /FATAL: repo does not exist, or you are not authorised/
 
     # auto-create using perms
     echo READERS u2 | glt perms u1 -c foo/u1/baz