smart http mode in git 1.8.2 and above...

...needs a specific header at a certain point

see 4656bf47fca857df51b5d6f4b7b052192b3b2317 in git.git for an
explanation.

People who use the old gitolite with newer gits will probably see error
messages that don't spell out the user, the repo, the operation, etc
clearly.

Of course, this only applies to the case where the "first check", where
the user has NO access to the repo and is being kicked out even before
control passes to git-*-pack.  Any errors after that should work fine
anyway, since they come direct from git-http-backend, not gitolite.
(minor) git version change necessitated some test changes
a couple of low level file perm changes...

(all thanks to Peter Wu; see [1])

1.  updating ~/projects.list (or whatever you have GITWEB_PROJECTS_LIST
    pointing to) becomes an issue when the global UMASK is too tight and
    you're loosening it for specific repos.  Those repos can be seen
    (presumably you're using repoumask or something) but the
    projects.list is invisible.

    This patch makes gitolite honor the perms for that file if it
    already exists.  This allows the admin to manually loosen its perms
    just once and forget about it after that.  (The alternative would be
    something ghastly like GITWEB_PROJECTS_LIST_PERMS in the rc file!)

2.  while discussing this it turned out that RepoUmask had a... well
    let's call it a "problem" for argument's sake ;-)

    The files that get created on "git init" (usually HEAD, description,
    info/exclude, and gl-perms) were left with the executable bit turned
    on.  You can see the thread [1] below for why I don't really care
    about this, but since the fix it only one line, I may as well...

[1]: https://groups.google.com/forum/#!topic/gitolite/x-bQX_W82rw
repo-specific hooks
set umask as early as possible