On Mon, Mar 02, 2009 at 11:56:57PM -0800, Junio C Hamano wrote:
> > I concur w/Jeff and I think git probably should not as well. I think
> > that instead adding it to init might be interesting
>
> The thing is Jeff and Shawn already rejected that route.
Since when do you listen to me? ;P
I think there are actually two issues to be resolved, though:
1. What is a standardized way for clients to ask for repo creation?
2. How do users trigger that repo creation.
I think once you have (1), then (2) is easy. You can have "git init
host:dir", "git push --init remote", or whatever, and they can all
trigger the same mechanism. For systems which have an out-of-band
method, they can continue to behave as they have, or they can hook into
the standardized mechanism as if they were clients themselves. So there
is not that much point in debating (2), I think, until there is a
working (1).
Now (1) is much harder. Some parameters come from the user, but some
(including whether creation is allowed at all) must come from the site
administrator. And some site administrators will a hook to do whatever
site-specific magic they need.
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).
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
