From: Jay Soffian <jaysoffian@gmail.com>
Date: Tue, 03 Mar 2009 19:57:15 GMT
Subject: Re: Subject: [PATCH] Push to create
Message-ID: <76718490903031157o2938d46cl6c33e78cf64ad9d1@mail.gmail.com>
In-Reply-To: <20090303082318.GB3158@coredump.intra.peff.net>

On Tue, Mar 3, 2009 at 3:23 AM, Jeff King <peff@peff.net> wrote:
>
> What about the client just calling init-serve on the server as a program
> which does whatever it wants to create a repo? The shipped default would
> be:
>
>  #!/bin/sh
>  echo >&2 Sorry, repo creation not allowed.
>  exit 1
>
> Sites who want to give their users full creation access would do (and
> obviously the --mkdir option would need to be added):
>
>  #!/bin/sh
>  exec git init --mkdir "$@"
>
> Sites which want to restrict can do:
>
>  #!/bin/sh
>  for i in "$@"; do
>    case "$i" in
>    --bare) ;;
>         *) echo >&2 Forbidden argument: $i; exit 1 ;;
>    esac
>  done
>  exec git init --mkdir "$@"
>
> Sites like GitHub or Gerrit can munge the arguments as appropriate. They
> could even allow site-specific options if they wanted as long as they
> were syntactically correct (i.e., "git init --gerrit-base=foo remote"
> would pass the argument through to the remote unharmed).

FWIW, I like this proposal. The only issue I have which I think simply
cannot be reconciled is this: it doesn't do anything to help a user
that expects "git push --init ssh://..." to "just work". (And here I'm
assuming push --init just calls init --remote under the covers.) The
reason is that such a user is probably just using the git supplied by
their vendor, and thus remote creation is likely disabled by default.
The best I can come up with is a different error message:

"Sorry, remote repo creation not allowed. To enable it, blah blah blah"

So at least the user has a clue that git can help them here, but there
are security reasons it does not do so by default.

j.