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.
gitolite setup fails to check admin pubkey, because $text always
contains 2 or more lines after tsh_try() (the key and -n).
[committer adds:
I wasn't sure if 'printf' would work on cygwin, so I chose what
looked like a safer option, but apparently it wasn't safe enough and
fell afoul of Solaris.
Anyway I managed to check (using a small test program) with someone
who runs gitolite on cygwin, and it works.
If you're wondering why I didn't just use echo followed by chomp(),
that would of course have been the easy way out but I wanted to see
how you'd do it without a post-processing option. It became a
frustrating challenge of sorts because it seems such a trivial thing!
]
The fix is easy enough, but I hate having to code work-arounds for
proprietary OSs when the same code works fine on Linux and BSD.
/me wisely avoids words like posix in his rant ;-)
Thanks to Franck Zoccolo for help in finding what the problem was and
when and why it occurred.
----
Someday there will be some issue that requires a fix with significant
code change (or worse, a change that is incompatible with Linux), and I
will probably refuse. Of course, I will be properly regretful about my
inability to fix it.[1]
- migration and non-core reachable from master-toc now
- migration flow changed. install.mkd, migration section, is [migr]
now, drives the whole thing now, links to g2migr
- more details on how to wipe out old gitolite
plus some minor fixes
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_)
(manually tested, no test script)
the whimsically named "D" command deletes repos, and is the opposite of
the "C" permission that enables the user to create one in the first
place. See the usage message for user info, and look in the comments of
the code itself for admin info.
- minor typo fixes, clarifications, etc.
- keep sts.html url consistent, because many people link to
http://sitaramc.github.com/gitolite/sts.html
- create a common migration doc, so the old 'migr.html' does not 404
when g3 docs become "main"
- progit doc done
- add gitosis convert script (FWIW)
- a minor comment fix to Sugar.pm
...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.
- explicit 'list' gives way to mindmap, ...
- 'fm2mt.pl' to produce master-toc.mkd from the mindmap
- mkdoc no longer ignores master-toc.mkd, calls fm2mt.pl itself
and LOTS of changes to the actual docs
I don't know why I had put VERSION in GL_ADMIN_BASE, which is pretty
stupid. It should be in GL_BINDIR.
It also has nothing to do with setup -- the file needs to be generated
at 'install' time.
because the loop in the code below was sending out $repo =
'./gitolite-admin.git' to hook_1(), inside which there is an explicit
check for 'gitolite-admin', which of course doesn't match
'./gitolite-admin'!
Sitaram Chamarty
Thomas Hager
gitolite tester