[Mostly I'm sending this so I can add a "TODO" label to it in my gmail.] :-)

With modern git, setting up a remote bare repo that you can push to is
finally down to a reasonable number of commands:

$ ssh remote git init --bare myproject.git
$ git remote add -m master origin remote:myproject.git
$ git push -u origin master

But we can do better. I was thinking something like:

$ git remote init [--push] [--mirror] <name> <ssh_url>

This would perform all of the steps above, except for the push itself,
unless given --push (in which case, that too). This is meant to
simplify what I believe is the common case of setting up remote repos.

j.
--

[ message continues ]

Couple of concerns:

- That seems awfully ssh-specific[1]...
- How remote end could deny the operation, modify paths and/or 
get post-creation notification?
- How to handle systems that would autocreate the repository anyway
if push was attempted?

[1] Well, its not like one would want to do that with gits:// anyway,
since there's probably gitolite install on other end anyway...

-Ilari
--

[ message continues ]

On Tue, Apr 13, 2010 at 3:58 PM, Ilari Liusvaara

Of course it is. It's not meant to cover every scenario, just what I

Huh? Obviously this only works if you've got remote shell access, and
that's the only scenario it's intended to cover. As I said, it just


And this isn't for that scenario.

j.
--

[ message continues ]

I just reviewed the giant thread from last time this came up:

  http://thread.gmane.org/gmane.comp.version-control.git/111799

A few things I noticed were:

  1. People seemed to want "git push --create". I think integrating it
     with git-remote would be more convenient for most of my use cases,
     but I can also see people wanting a one-off push-create without
     worrying about configured remotes (e.g., because it is just a drop
     point that they are going to delete later). So any code could
     hopefully be used for both cases.

  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. There was some
     concern about having administrators turn this feature on
     explicitly, in case their site needs extra configuration. Thinking
     on it more, I don't know that we need to do anything special there.

     If a user has shell access, then there is no point in protecting the
     site from them. They can already log in and run "git init". For
     restricted users running "git shell", running "git init" is already
     disallowed. We could add an option to enable it (defaulting to
     off), and optionally translate "git init" invocations to something
     else (so a site with special needs could intercept "git init" to
     run their own script which would do whatever site-specific things
     they wanted, as long as a repo existed in the end).

     Similarly, git-daemon and smart http could probably support the
     same thing, defaulting to off.

     So while it looks ssh-specific, I suspect it could actually be
     transport-agnostic. It's just that most transports wouldn't have it
     turned on by default.

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

  2. The "git init $dir" syntax is what makes it reasonably transport
    ...
[ message continues ]

I think it is fine to have all of the following, triggering the same
underlying mechanism:

	git init over.there.com:myproject.git
        git remote add --create another over.there.com:myproject.git
        git push --create over.there.com:myproject.git master

Even though I'll say that we probably shouldn't have the second one in the

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

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.

Also, wouldn't this sequence be more natural?

	git remote add another over.there.com:myproject.git
        git push another

That is, (1) "git remote add" would happily allow creating a local
description for a remote repository to be created; and optionally (2) "git
push" into a configured remote may not need an explicit "--create" (we may

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

... but then I don't see what it has to do with the "transport agnostic"
part of your comment.
--

[ message continues ]

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

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

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

[ message continues ]