This patch adds instructions for configuring Gitolite and Apache 2.x to make repositories available to both ssh and http clients. [minor fixups by committer]
thanks to milki for all the efforts! Details: - partial-copy fell afoul of BSD not having $RANDOM - test suite: fix bad GNU sort with good perl sort - test suite: fix md5sum dependency (which BSD doesn't have or can't easily have or requires extra options or whatever...), by doing it in perl. (Requires Digest::MD5, which is probably available anyway, but since this is only for the test suite, meh!)
I had not remembered that the 'tc' subcommand in tsh adds *text* that contains the current time, so commit SHAs were changing. Thanks to milki for catching this, and in fact being the only person who ever appears to have attempted to run the test suite at all!
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 in perl) is 'POST_CREATE', and if it is, take the *next* argument as a repo name that may have changed.
…xist thanks to EugeneKay for catching this
- access command allows checking ^C - ^C check will fail when the repo exists
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! ]
writable() in Writable.pm renamed to "access_1" to be consistent; i.e., reflect the trigger name
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.
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_)