The initial fetch of a new repo which has 'upstream' read-only mirroring
configured will cause a spurious error concerning FETCH_HEAD not yet
existing. This silences the error.
Add a special variable `%GL_CREATOR` to the the git-config trigger that
is replaced by the name of the repository creator (if any).
This can be useful to set up the default owner configuration for wild
repositories.
Example:
repo assignments/CREATOR/a[0-9][0-9]
C = @students
RW+ = CREATOR
config gitweb.owner = %GL_CREATOR
----
committer added an if condition to the s/// line.
i.e., a client fetch will invoke the push, (subject to 'nice' setting),
but you can also force a fetch regardless of last fetch time by running
this command directly on the server:
gitolite ../triggers/upstream fetch <reponame>
Also, use FETCH_HEAD instead of own sentinel file (idea courtesy Luke Lu)
If a user has multiple keys, ssh-authkeys-shell-users will only add the
"-s" flag to the first key it finds. Change the substitution to apply
to all matching lines and hence grant shell access to all of the user's
keys.
Signed-off-by: John Keeping <john@keeping.me.uk>
(1) the backward compat breakage: you can't create empty-valued config
keys anymore. That is, you can't do the eqvt of the following shell
command using gitolite
git config foo.bar ""
(2) fixed a bug where this:
repo foo
config foo.bar =
when queried using
gitolite git-config -r foo .
would return even the empty valued ones, which -- remember! -- are
not supposed to exist anymore.
Fixing this bug allows situations like this to not show the admin
repo in gitweb:
repo [a-z].*
config gitweb.owner = P-h B
repo gitolite-admin
config gitweb.owner =
----
background...
Somewhere in g3 (well actually in 057506b), we lost the ability to
distinguish
config foo.bar = ""
from
config foo.bar =
I decided that conflating them is more intuitive for most people,
because a survey [1] revealed that no one seemed to want the equivalent
of the following shell command:
----
[1] ...of a (small prime greater than 1) number of people on #git
The POST_CREATE trigger is called when
* a user creates a new "wild" repo,
* a user uses the "perms" command, and
* a user uses the "fork" command.
The trigger calls 3 programs (see rc file):
post-compile/update-git-configs
post-compile/update-gitweb-access-list
post-compile/update-git-daemon-access-list
(They are also called by the POST_COMPILE trigger, by the way.)
However, the 3 programs shown are a bit wasteful -- they run through
*all* the repos when really only *one* repo has been affected.
This patch
* passes the repo name to the 3 programs (duh!)
* adds the optimisation to the first of the 3 programs listed above
(the one dealing with 'git config').
For the other two programs (gitweb and git-daemon), you have 3 choices:
* if you don't have too many repos, ignore the problem.
* take out the 2nd and 3rd lines from the POST_CREATE list in the rc
file, so they don't run.
Then run 'gitolite trigger POST_COMPILE' from cron at regular
intervals. (Note that is POST_COMPILE not POST_CREATE!) However,
this means that gitweb and daemon permissions won't be current
immediately after someone adds a new repo or sets perms etc.; they
get updated only on the next cron run.
* patch the programs to add this optimisation (and send me the
patches). The optimisation would check if arg-1 ($1 in shell,
$ARGV[0] in perl) is 'POST_CREATE', and if it is, take the *next*
argument as a repo name that may have changed.
I must have blindly converted from some shell-thinking/shell-code for
these to have slipped through!
(found when doing an audit of all system, exec, ``, qx, and tsh_)
...now that triggers are not restricted to external programs and can be
perl code called by gitolite-shell (thus in the same PID), there's no
need to compute and pass along the times() array.
This also changes the arguments to POST_GIT; they're now the same as
PRE_GIT's.
someone reported an error on "my $_" (presumably old perl) but I now
realise the whole map is useless; both the lists concerned have already
been chomped.
...there was one real bug, plus I had forgotten to put a comented out
line in the rc file, but most of the rest of the effort was moving the
test script over.
oh and I'd also forgotten to move this from 'commands' to 'triggers' :-)
...otherwise 'gitolite help' was getting too confusing, mixing up stuff
that users should not be running directly (even on the server)
----
implementation notes:
those who are worried about the '../triggers/' in various parts of the
code here, remember you can only do that from a command line on the
server. Remote users can only use commands that have been explicitly
listed in the COMMANDS hash in the rc file. This means they can't even
access other commands in the same directory as, say, the 'info' command,
so a '../' is definitely not going to work.
Sitaram Chamarty
Eugene E. Kashpureff Jr
Patrick Westerhoff
Randal L. Schwartz
John Keeping
Thomas Hager