On Wed, Apr 14, 2010 at 06:28:54AM -0700, Junio C Hamano wrote: > > 2. We talked about an "init-serve" program back then. These days, "git > > init $dir" works, so I don't see the need for one. > > I don't get this; the primary point of init-serve was _not_ about the lack > of an internal mkdir in "git init", but was about having an interface to > trigger "git init" in a transport agnostic way. The implementation of the > remote side mechanism could use "git init $dir" instead of "mkdir $dir && > cd $dir && git init" these days, but I think that is a very minor point. Yeah, my explanation was a bit confused. What I meant was that back then, we needed some wrapper, because you can't tell git-shell "mkdir x && cd x && git init". But these days, "git init" could serve as that wrapper. Which leaves the question of whether we need a _separate_ git program to do init serving. I'm not sure we do. For regular shell users, there is no point in restricting them; they could just run "git init" themselves. And by using "git init" directly without any configuration from the remote site, things will just work for such users. For users of a restricted shell, the site administrator would have to configure git-shell to allow "git init". But I think it makes sense for git-shell to support redirecting "git init" to "git-my-custom-init" internally. So the client end knows it just needs to say "git init" whether it is a real shell or a restricted git shell. The lingua franca for "make me a new repository" is "git init $dir". > > Two questions/reservations looking at your prototype: > > > > 1. Should it push just master, or perhaps --all? Should it actually be > > two separate options to "git remote add" (--push and --init?). > > I would say "git remote add --create ..." shouldn't even have push option; > rather, don't put --create in "git remote". > > "git push --create" would behave just like normal "push", and the above > question does not even come into the picture. "push" will push whatever > it would normally push if the repository existed, period. Yeah, that is much more natural, I think, and resolves all of the "what should I push" questions. And it keeps remote's job to "manipulate config for remotes" which is the direction it has been going on (e.g., the recent conversion of "git remote update" to "git fetch --all"). > > 2. The "git init $dir" syntax is what makes it reasonably transport > > agnostic. > > I am not sure what you are getting at here. Are you suggesting that $dir > could be a URL (i.e. "git init over.there.com:myproject.git")? Or are you > still thinking in terms of how "init-serve" (or its equivalent that is > either run directly via ssh or from transports supported by git) is > implemented using "git init"? It seems the latter judging from this,... The latter. Really, I was conflating two issues: how the ssh transport can handle both regular and restricted shells, and how other transports handle it. The first I discussed above in a hopefully more clear way. For the latter, on thinking more, it is really irrelevant. What the git-daemon refers to as the "init" service does not necessarily have to map to a command. So it is not really important. > > ... But that syntax was not introduced until 1.6.5, so you > > will run into problems with remotes running older versions of git. > > ... but then I don't see what it has to do with the "transport agnostic" > part of your comment. Again, me conflating issues. What I meant to say was that for the blind run-this-command-over-ssh transport, this will not work with older versions of git on the remote side. But if you make it truly ssh-specific, you can do "mkdir $dir && cd $dir && git init" which would work with any version. -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