{"thread":{"id":"23447","subject":"TODO: git should be able to init a remote repo","startedAt":"2010-04-13T17:30:44Z","lastAt":"2010-04-14T13:46:46Z","messageCount":6,"participants":["Jay Soffian","Ilari Liusvaara","Jeff King","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"139427","messageId":"i2i76718491004131030sc2f8ffa3u97a91aa9a57923b5@mail.gmail.com","threadId":"23447","inReplyTo":null,"subject":"TODO: git should be able to init a remote repo","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2010-04-13T17:30:44Z","receivedAt":"2010-04-13T17:30:44Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"[Mostly I'm sending this so I can add a \"TODO\" label to it in my gmail.] :-)\n\nWith modern git, setting up a remote bare repo that you can push to is\nfinally down to a reasonable number of commands:\n\n$ ssh remote git init --bare myproject.git\n$ git remote add -m master origin remote:myproject.git\n$ git push -u origin master\n\nBut we can do better. I was thinking something like:\n\n$ git remote init [--push] [--mirror] \n\nThis would perform all of the steps above, except for the push itself,\nunless given --push (in which case, that too). This is meant to\nsimplify what I believe is the common case of setting up remote repos.\n\nj.\n"},{"id":"139431","messageId":"20100413195826.GA11597@LK-Perkele-V2.elisa-laajakaista.fi","threadId":"23447","inReplyTo":"i2i76718491004131030sc2f8ffa3u97a91aa9a57923b5@mail.gmail.com","subject":"Re: TODO: git should be able to init a remote repo","fromName":"Ilari Liusvaara","fromEmail":"ilari.liusvaara@elisanet.fi","sentAt":"2010-04-13T19:58:26Z","receivedAt":"2010-04-13T19:58:26Z","isPatch":false,"sender":{"key":"ilari.liusvaara@elisanet.fi","avatar":null},"body":"On Tue, Apr 13, 2010 at 01:30:44PM -0400, Jay Soffian wrote:\n> [Mostly I'm sending this so I can add a \"TODO\" label to it in my gmail.] :-)\n> \n> With modern git, setting up a remote bare repo that you can push to is\n> finally down to a reasonable number of commands:\n> \n> $ ssh remote git init --bare myproject.git\n> $ git remote add -m master origin remote:myproject.git\n> $ git push -u origin master\n> \n> But we can do better. I was thinking something like:\n> \n> $ git remote init [--push] [--mirror] \n> \n> This would perform all of the steps above, except for the push itself,\n> unless given --push (in which case, that too). This is meant to\n> simplify what I believe is the common case of setting up remote repos.\n\nCouple of concerns:\n\n- That seems awfully ssh-specific[1]...\n- How remote end could deny the operation, modify paths and/or \nget post-creation notification?\n- How to handle systems that would autocreate the repository anyway\nif push was attempted?\n\n[1] Well, its not like one would want to do that with gits:// anyway,\nsince there's probably gitolite install on other end anyway...\n\n-Ilari\n"},{"id":"139436","messageId":"q2j76718491004131442q5ec8588en75611f97af26fac@mail.gmail.com","threadId":"23447","inReplyTo":"20100413195826.GA11597@LK-Perkele-V2.elisa-laajakaista.fi","subject":"Re: TODO: git should be able to init a remote repo","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2010-04-13T21:42:25Z","receivedAt":"2010-04-13T21:42:25Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Tue, Apr 13, 2010 at 3:58 PM, Ilari Liusvaara\n wrote:\n> Couple of concerns:\n>\n> - That seems awfully ssh-specific[1]...\n\nOf course it is. It's not meant to cover every scenario, just what I\nfeel is a common one.\n\n> - How remote end could deny the operation, modify paths and/or\n> get post-creation notification?\n\nHuh? Obviously this only works if you've got remote shell access, and\nthat's the only scenario it's intended to cover. As I said, it just\nsimplifies 3 commands down to 1.\n\n> - How to handle systems that would autocreate the repository anyway\n> if push was attempted?\n\nAgain, that is not the use case \"git remote init\" is for.\n\n> [1] Well, its not like one would want to do that with gits:// anyway,\n> since there's probably gitolite install on other end anyway...\n\nAnd this isn't for that scenario.\n\nj.\n"},{"id":"139464","messageId":"20100414094048.GA19344@coredump.intra.peff.net","threadId":"23447","inReplyTo":"i2i76718491004131030sc2f8ffa3u97a91aa9a57923b5@mail.gmail.com","subject":"Re: TODO: git should be able to init a remote repo","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-04-14T09:40:49Z","receivedAt":"2010-04-14T09:40:49Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Apr 13, 2010 at 01:30:44PM -0400, Jay Soffian wrote:\n\n> $ ssh remote git init --bare myproject.git\n> $ git remote add -m master origin remote:myproject.git\n> $ git push -u origin master\n> \n> But we can do better. I was thinking something like:\n> \n> $ git remote init [--push] [--mirror] \n\nI just reviewed the giant thread from last time this came up:\n\n http://thread.gmane.org/gmane.comp.version-control.git/111799\n\nA few things I noticed were:\n\n 1. People seemed to want \"git push --create\". I think integrating it\n with git-remote would be more convenient for most of my use cases,\n but I can also see people wanting a one-off push-create without\n worrying about configured remotes (e.g., because it is just a drop\n point that they are going to delete later). So any code could\n hopefully be used for both cases.\n\n 2. We talked about an \"init-serve\" program back then. These days, \"git\n init $dir\" works, so I don't see the need for one. There was some\n concern about having administrators turn this feature on\n explicitly, in case their site needs extra configuration. Thinking\n on it more, I don't know that we need to do anything special there.\n\n If a user has shell access, then there is no point in protecting the\n site from them. They can already log in and run \"git init\". For\n restricted users running \"git shell\", running \"git init\" is already\n disallowed. We could add an option to enable it (defaulting to\n off), and optionally translate \"git init\" invocations to something\n else (so a site with special needs could intercept \"git init\" to\n run their own script which would do whatever site-specific things\n they wanted, as long as a repo existed in the end).\n\n Similarly, git-daemon and smart http could probably support the\n same thing, defaulting to off.\n\n So while it looks ssh-specific, I suspect it could actually be\n transport-agnostic. It's just that most transports wouldn't have it\n turned on by default.\n\nTwo questions/reservations looking at your prototype:\n\n 1. Should it push just master, or perhaps --all? Should it actually be\n two separate options to \"git remote add\" (--push and --init?).\n\n 2. The \"git init $dir\" syntax is what makes it reasonably transport\n agnostic. But that syntax was not introduced until 1.6.5, so you\n will run into problems with remotes running older versions of git.\n I think it is OK to say that this feature is not supported on older\n versions (otherwise we _must_ be ssh-specific), but I'm not sure\n how graceful the failure will be.\n\n-Peff\n"},{"id":"139473","messageId":"7viq7urwmh.fsf@alter.siamese.dyndns.org","threadId":"23447","inReplyTo":"20100414094048.GA19344@coredump.intra.peff.net","subject":"Re: TODO: git should be able to init a remote repo","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-04-14T13:28:54Z","receivedAt":"2010-04-14T13:28:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Tue, Apr 13, 2010 at 01:30:44PM -0400, Jay Soffian wrote:\n>\n>> $ ssh remote git init --bare myproject.git\n>> $ git remote add -m master origin remote:myproject.git\n>> $ git push -u origin master\n>> \n>> But we can do better. I was thinking something like:\n>> \n>> $ git remote init [--push] [--mirror] \n>\n> I just reviewed the giant thread from last time this came up:\n>\n> http://thread.gmane.org/gmane.comp.version-control.git/111799\n\nThanks for a pointer to an amusing read.\n\n> A few things I noticed were:\n>\n> 1. People seemed to want \"git push --create\". I think integrating it\n> with git-remote would be more convenient for most of my use cases,\n> but I can also see people wanting a one-off push-create without\n> worrying about configured remotes (e.g., because it is just a drop\n> point that they are going to delete later). So any code could\n> hopefully be used for both cases.\n\nI think it is fine to have all of the following, triggering the same\nunderlying mechanism:\n\n\tgit init over.there.com:myproject.git\n git remote add --create another over.there.com:myproject.git\n git push --create over.there.com:myproject.git master\n\nEven though I'll say that we probably shouldn't have the second one in the\nlater part of this message.\n\n> 2. We talked about an \"init-serve\" program back then. These days, \"git\n> init $dir\" works, so I don't see the need for one.\n\nI don't get this; the primary point of init-serve was _not_ about the lack\nof an internal mkdir in \"git init\", but was about having an interface to\ntrigger \"git init\" in a transport agnostic way. The implementation of the\nremote side mechanism could use \"git init $dir\" instead of \"mkdir $dir &&\ncd $dir && git init\" these days, but I think that is a very minor point.\n\n> Two questions/reservations looking at your prototype:\n>\n> 1. Should it push just master, or perhaps --all? Should it actually be\n> two separate options to \"git remote add\" (--push and --init?).\n\nI would say \"git remote add --create ...\" shouldn't even have push option;\nrather, don't put --create in \"git remote\".\n\n\"git push --create\" would behave just like normal \"push\", and the above\nquestion does not even come into the picture. \"push\" will push whatever\nit would normally push if the repository existed, period.\n\nAlso, wouldn't this sequence be more natural?\n\n\tgit remote add another over.there.com:myproject.git\n git push another\n\nThat is, (1) \"git remote add\" would happily allow creating a local\ndescription for a remote repository to be created; and optionally (2) \"git\npush\" into a configured remote may not need an explicit \"--create\" (we may\nstill want to insist on --create to avoid a mistyped URL---I dunno).\n\n> 2. The \"git init $dir\" syntax is what makes it reasonably transport\n> agnostic.\n\nI am not sure what you are getting at here. Are you suggesting that $dir\ncould be a URL (i.e. \"git init over.there.com:myproject.git\")? Or are you\nstill thinking in terms of how \"init-serve\" (or its equivalent that is\neither run directly via ssh or from transports supported by git) is\nimplemented using \"git init\"? It seems the latter judging from this,...\n\n> ... But that syntax was not introduced until 1.6.5, so you\n> will run into problems with remotes running older versions of git.\n\n... but then I don't see what it has to do with the \"transport agnostic\"\npart of your comment.\n"},{"id":"139476","messageId":"20100414134645.GA12592@coredump.intra.peff.net","threadId":"23447","inReplyTo":"7viq7urwmh.fsf@alter.siamese.dyndns.org","subject":"Re: TODO: git should be able to init a remote repo","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-04-14T13:46:46Z","receivedAt":"2010-04-14T13:46:46Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Apr 14, 2010 at 06:28:54AM -0700, Junio C Hamano wrote:\n\n> > 2. We talked about an \"init-serve\" program back then. These days, \"git\n> > init $dir\" works, so I don't see the need for one.\n> \n> I don't get this; the primary point of init-serve was _not_ about the lack\n> of an internal mkdir in \"git init\", but was about having an interface to\n> trigger \"git init\" in a transport agnostic way. The implementation of the\n> remote side mechanism could use \"git init $dir\" instead of \"mkdir $dir &&\n> cd $dir && git init\" these days, but I think that is a very minor point.\n\nYeah, my explanation was a bit confused. What I meant was that back\nthen, we needed some wrapper, because you can't tell git-shell \"mkdir x\n&& cd x && git init\". But these days, \"git init\" could serve as that\nwrapper.\n\nWhich leaves the question of whether we need a _separate_ git program to\ndo init serving. I'm not sure we do. For regular shell users, there is\nno point in restricting them; they could just run \"git init\" themselves.\nAnd by using \"git init\" directly without any configuration from the\nremote site, things will just work for such users.\n\nFor users of a restricted shell, the site administrator would have to\nconfigure git-shell to allow \"git init\". But I think it makes sense for\ngit-shell to support redirecting \"git init\" to \"git-my-custom-init\"\ninternally. So the client end knows it just needs to say \"git init\"\nwhether it is a real shell or a restricted git shell. The lingua franca\nfor \"make me a new repository\" is \"git init $dir\".\n\n> > Two questions/reservations looking at your prototype:\n> >\n> > 1. Should it push just master, or perhaps --all? Should it actually be\n> > two separate options to \"git remote add\" (--push and --init?).\n> \n> I would say \"git remote add --create ...\" shouldn't even have push option;\n> rather, don't put --create in \"git remote\".\n> \n> \"git push --create\" would behave just like normal \"push\", and the above\n> question does not even come into the picture. \"push\" will push whatever\n> it would normally push if the repository existed, period.\n\nYeah, that is much more natural, I think, and resolves all of the \"what\nshould I push\" questions. And it keeps remote's job to \"manipulate\nconfig for remotes\" which is the direction it has been going on (e.g.,\nthe recent conversion of \"git remote update\" to \"git fetch --all\").\n\n> > 2. The \"git init $dir\" syntax is what makes it reasonably transport\n> > agnostic.\n> \n> I am not sure what you are getting at here. Are you suggesting that $dir\n> could be a URL (i.e. \"git init over.there.com:myproject.git\")? Or are you\n> still thinking in terms of how \"init-serve\" (or its equivalent that is\n> either run directly via ssh or from transports supported by git) is\n> implemented using \"git init\"? It seems the latter judging from this,...\n\nThe latter. Really, I was conflating two issues: how the ssh transport\ncan handle both regular and restricted shells, and how other transports\nhandle it. The first I discussed above in a hopefully more clear way.\nFor the latter, on thinking more, it is really irrelevant. What the\ngit-daemon refers to as the \"init\" service does not necessarily have to\nmap to a command. So it is not really important.\n\n> > ... But that syntax was not introduced until 1.6.5, so you\n> > will run into problems with remotes running older versions of git.\n> \n> ... but then I don't see what it has to do with the \"transport agnostic\"\n> part of your comment.\n\nAgain, me conflating issues. What I meant to say was that for the blind\nrun-this-command-over-ssh transport, this will not work with older\nversions of git on the remote side. But if you make it truly\nssh-specific, you can do \"mkdir $dir && cd $dir && git init\" which would\nwork with any version.\n\n-Peff\n"}]}