Jeff King <peff@xxxxxxxx> writes: > On Tue, Apr 13, 2010 at 01:30:44PM -0400, Jay Soffian wrote: > >> $ 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> > > I just reviewed the giant thread from last time this came up: > > http://thread.gmane.org/gmane.comp.version-control.git/111799 Thanks for a pointer to an amusing read. > 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. 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 later part of this message. > 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. > 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. 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 still want to insist on --create to avoid a mistyped URL---I dunno). > 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,... > ... 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. -- 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