Robin Rosenberg <robin.rosenberg.lists@xxxxxxxxxx> writes: > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
