the most common problems an admin will see

an admin who refuses to read messages that show up on the screen, that is ;-)

(security) a different fix in place of 5fd9328

SECURITY NOTE: if you deleted or renamed a pubkey file after 5fd9328
went in (April 12th), please:

  - upgrade asap, then
  - go to your latest gitolite-admin clone and "git push -f"

Otherwise this is not urgent.

5fd9328 (and its minor successor 813a2a9) were about preventing the
gitolite admin from sneaking in files to src/ and hooks/ into
$GL_ADMINDIR.  It seemed easy enough to do this by converting the
path-less checkout to a with-paths checkout, but this has caused a worse
problem -- deleting a keydir/foo.pub now no longer has an effect; the
file still hangs around in the work tree.

Ouch!  (and thanks to teukka for noticing)

We now do this check as a separate step, so the checkout can revert to
being path-less.

changelog for v1.4

minor LFCR -> CRLF fix

Merge branch 'master' into pu (damn!)

stupid me; committed the easy install patch on master *and* pushed,
instead of on pu...

Since I dont want to rewind master, we end up with this completely
unnecessary merge.

doc/CHANGELOG added

Merge remote branch 'origin/pu'

Merge remote branch 'origin/pu'

auth: print permissions for @ALL also

I don't have a use for "@ALL" at all (pun not intended!) other than the
"testing" repo, but <teemu dot matilainen at iki dot fi> sent in a patch
to mark those repos with "R" and "W" in the permissions list, and I
started thinking about it.

This could actually be useful if we *differentiated* such access from
normal (explicit username) access.  From the "corporate environment"
angle, it would be nice if a project manager could quickly check if any
of his projects have erroneously been made accessible by @ALL.

So what we do now is print "@" in the corresponding column if "@ALL" has
the corresponding access.

Also, when someone has access both as himself *and* via @ALL, we print
the "@"; printing the "R" or "W" would hide the "@", and wouldn't
correctly satisfy the use case described above.

update hook: 'sub check_ref' to prepare for rebel+

factor out the code to check $ref into a sub; will help rebel+, which
wants (horrors!) to restrict based on PATH names too!