A gitolite POST_CREATE trigger is added to initialize the description
file in new repos.  This prevents the "Unnamed repository; edit this
file ..." string from being used by default.

This affects new repositories, existing projects will remain as is.

Signed-off-by: Malfurious <m@lfurio.us>

The previous version fails to handle nested branch names containing
slashes.  For example, if pushing a single new branch named
`feat/example`, the script would set HEAD to `feat` and remain dangling.

Signed-off-by: Malfurious <m@lfurio.us>

The previous content of gitolite.conf defined the standard access rules
for normalmode.  These are now moved to a new file which will be baked
into the gitolite docker image and not managed by the gitolite-admin
repository.

This will allow for easier management of the normalmode rules via this
git repository (aka, part of the normalmode distribution) and prevent
the need for user intervention and to stomp on gitolite-admin to adopt
new updates.  The goal is to give users nearly complete ownership of
their gitolite.conf file.

Added to the gitolite.conf template is a definition for a new @creators
group.  The normalmode rules are updated to permit only users from this
group to create and own new wildcard repositories.  This allows creating
new users which can only contribute to other's repos (as either a
MAINTAINER or CONTRIBUTOR), or access private repos.

As alluded by the previous paragraph, administrators may define private
repos within gitolite using normalmode.  This is done by manually
configuring them in gitolite.conf.  This use-case has always been
possible, but has only recently been tested to confirm that the access
restrictions are compatible with the rest of normalmode's operations.
(aka: Nothing is leaked via cgit, and the normalmode access rules don't
break anything).  Easing this use-case is another reason for the clean
separation of config files.

Signed-off-by: Malfurious <m@lfurio.us>

I'm considering this default behavior as a bug for normalmode.  The
creation of a repository via a read activity seems far too accidental
for my taste.  Repositories are created by pushing to them.

This does mean that:

    git clone <new-url>
    ...
    git push

is no longer a shorthand for:

    git init
    git remote add origin <new-url>
    ...
    git push

I'm ok with that.

Signed-off-by: Malfurious <m@lfurio.us>

Since it is now allowed to remove the remote default branch, this script
needs to handle cases where there are no branches following a push.

In this case, the `git symbolic-ref` command will fail, and we return
our standard warning for when HEAD is dangling.

Signed-off-by: Malfurious <m@lfurio.us>

The new installation procedure is to start with ./configure to set your
pubkey up for admin access.  The initialize script is updated to use an
active prompt, since as-is, CTRL-C won't properly terminate the script
to cancel.

Signed-off-by: Malfurious <m@lfurio.us>

Per docker image changes, this serves as an alternative entrypoint for
performing initial pubkey configuration.

Signed-off-by: Malfurious <m@lfurio.us>

This allows the branch considered the repo default to be deleted via
push.  I'm not totally opposed to allowing this, even though it's not
entirely necessary.  However, the ability to do this is now required by
the docker image entrypoint script.

Signed-off-by: Malfurious <m@lfurio.us>

The default gitolite.conf file is now patched in to the gitolite
installation in the docker image.  This is so that the intended version
of the file is used in the gitolite-admin repo from the very beginning.
This is made necessary by the decoupling of repo purposes.

Instead of using (literal) 'admin', '%ADMIN' will be substituted with
the actual admin username during `gitolite setup`.

Signed-off-by: Malfurious <m@lfurio.us>

Per the previous commit, site-local code is now to be located directly
in the git user's home directory, as static content in the docker image.
Correct this setting in the RC file.

Signed-off-by: Malfurious <m@lfurio.us>