Robin Rosenberg <robin.rosenberg.lists@dewire.com> writes:

quoted text
> git remote add someremote someurl
> git push --init someremote/someurl
>
> The implementation would invoke receive pack on the receiving side with
> an --init option. On the server side the repository would be created and
> initialized just as one had executed and mkdir and git init --bare.

We saw this quite a number of times.  I think it's about time we did
something about it.

But I do not think it is a reasonable design to give receive-pack such an
option.

An easy alternative would be to issue the usual "mkdir && git init" shell
script before spawning receive-pack.  This will limit the feature to
pushing over the ssh transport, and pushing over the git protocol against
a loose git-daemon will not be able to support it.  Also I suspect this
will break sites managed by gitosis, where all repositories are held under
the same UNIX user identity, differenciated only via an environment it
sets based on the ssh key used to make the connection.

I wonder if you can take a middle ground alternative:

 - Make "git push --init [--shared] $site:$there" and "git push --init
   [--shared] git://$site/$there" run "git init -D [--shared] $there"
   followed by "git receive-pack $there";

 - Teach "-D $there" option to "git init", which does an "mkdir -p $it &&
   chdird $it" before it does its work.
 
 - Teach "git daemon" about the "init" service, which is disabled by
   default, and can be enabled just like you can enable receive-pack
   there.

If sites like repo.or.cz, github, or managed with gitosis want to use
this, I think you might further need to give "git init -D $there" a hook
to control who can create new repositories at which location (gitosis is
the most interesting case, as described above).
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html