Re: TODO: git should be able to init a remote repo

On Wed, Apr 14, 2010 at 06:28:54AM -0700, Junio C Hamano wrote:

quoted

  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".

quoted

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").

quoted

  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.

quoted

     ... 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