bugfix: don't delete description file when running perms

thanks to drue on #gitolite for catching it
(minor) lint had syntax errors

thanks to xcat on #gitolite for catching it
(shows you how often it gets used I guess!)
Set Content-Type to text/plain for gitolite commands over http

Explicitly set "Content-Type: text/plain" for gitolite commands when
issued over http, so that it is possible to see the output with normal
browsers.

(At least) Apache httpd might set the Content-Type to something
different and triggers a download instead of showing the text directly.

Signed-off-by: Sven Strickroth <email@cs-ware.de>
new trigger: update-gitweb-daemon-from-options

another way to update gitweb and daemon access lists
(minor) macro buglets

  - allow parameter-less macros
  - allow macro body to start on next line
add more detail to error message

this error normally happens due to some permission issue on the log
file, but we weren't printing the actual cause, so it was confusing
CREATOR need only be a "word" in wild repo patterns

this was a v2 compat breakage, caught by Dominik Schäfer
(schaedpq at gmail)
fix bug in list-dangling-repos

Still, I would advise caution if you use this as a basis for deleting
repos from the file system.  A bug in this program could cause you to
lose important data!
D: allow rm and unlock to be disabled
minor bugly...

please remember we make up words here, like refex was a word we created
to mean "a regex that matches a ref".

A "bugly", then, is a bug that's merely ugly (and not a real problem!)
bug fix: perms propagation to slaves...

Sometime after v3.2, I fixed what looked like an information disclosure
issue, where a user could determine if an arbitrary repo existed or not,
even if he had no rights to see the repo.  This was:

    96cc2ea "new features relating to creating wild repos:"

Unfortunately, this appears to have broken gl-perms propagation to
slaves, because now running "perm -c" on an existing repo dies!

If you run

    git diff 96cc2ea^ <this commit> -- src/commands/perms

you'll see how simple the fix *should* have been :-(
perms batch mode confuses; print something to help

What happens is that running

    ssh git@host perms reponame

appears to hang, since it is waiting for STDIN.  I added a message to
help, since we don't want users losing files accidentally!

(The other alternative is to add a specific option for batch mode, but
this is backward incompatible for people who have scripts that may be
doing this).

thanks to Caleb Cushing for catching this

----

The "make sure Ctrl-C gets caught" thing needs some explanation.

Without it, a user could inadvertently lose his gl-perms file if he ran
the command in batch mode.  You'd think that the Ctrl-C would hit the

    for (<>) {

line and bail, but it manages to reach the

    _print( $pf, @a );

line somehow.  Even trapping SIG INT does not help.

I suspect it is to do with how signals are propagated by ssh across a
"no-pty" session, but am not sure.
v3.3
list-dangling-repos: are we there yet?

<sigh>First I forgot @groups that may contain repos and patterns, then I
forgot patterns where the CREATOR token is used (this is the fix here).
on removing a repo...

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