{"thread":{"id":"33218","subject":"[ITCH] Specify refspec without remote","startedAt":"2013-03-18T16:58:59Z","lastAt":"2013-04-13T05:07:56Z","messageCount":68,"participants":["Ramkumar Ramachandra","Jeff King","Duy Nguyen","Holger Hellmuth (IKS)","Junio C Hamano","Jonathan Nieder"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"211583","messageId":"CALkWK0nYECHZaxit9jR-tS=7fXyOP5dy6mqUz0DKmbTRU-xRNw@mail.gmail.com","threadId":"33218","inReplyTo":null,"subject":"[ITCH] Specify refspec without remote","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-03-18T16:58:59Z","receivedAt":"2013-03-18T16:58:59Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Hi,\n\nThis has irritated me for a long time. I often end up doing:\n\n $ git push master:master +pu:pu\n\nonly to get an error, because I have to specify the remote before\nspecifying the refspec. I find this ugly because I rarely want to\npush to a remote that is different from the one configured, but often\nwant to specify my own refspec (say which branches to push, force\npush). Ofcourse, the same is the case while fetching.\n\nIs there a reason for the remote not being optional, or are we just\nwaiting for a patch? The only problem I can foresee is very minor:\nthere is a ref with the same name as a remote; in this case, we'd have\nto specify both the remote and the ref.\n\nThanks.\n\nRam\n"},{"id":"211584","messageId":"20130318170804.GA15924@sigill.intra.peff.net","threadId":"33218","inReplyTo":"CALkWK0nYECHZaxit9jR-tS=7fXyOP5dy6mqUz0DKmbTRU-xRNw@mail.gmail.com","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-03-18T17:08:04Z","receivedAt":"2013-03-18T17:08:04Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Mar 18, 2013 at 10:28:59PM +0530, Ramkumar Ramachandra wrote:\n\n> This has irritated me for a long time. I often end up doing:\n> \n> $ git push master:master +pu:pu\n\nMe too.\n\n> Is there a reason for the remote not being optional, or are we just\n> waiting for a patch? The only problem I can foresee is very minor:\n> there is a ref with the same name as a remote; in this case, we'd have\n> to specify both the remote and the ref.\n\nI think the ambiguity is a little more complex than that, because we\ncannot enumerate the universe of all remotes. Keep in mind that we can\ntake either a configured remote or a URL (or ssh host). So what does:\n\n git push foo:bar\n\nmean? Is it pushing \"refs/heads/foo\" to \"refs/heads/bar\" on \"origin\"? Or\nis it using the default refspecs to push to the \"bar\" repo on the host\n\"foo\" over ssh?\n\nSo you would need some heuristics based on whether something was a valid\nrefspec, or could be a valid remote name or URL.\n\n-Peff\n"},{"id":"211645","messageId":"CALkWK0=WCsXErHft9RbDOeehon7E2oCj5-YT6Ph+8bLFW-5JaQ@mail.gmail.com","threadId":"33218","inReplyTo":"20130318170804.GA15924@sigill.intra.peff.net","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-03-19T09:58:12Z","receivedAt":"2013-03-19T09:58:12Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Jeff King wrote:\n> On Mon, Mar 18, 2013 at 10:28:59PM +0530, Ramkumar Ramachandra wrote:\n>> Is there a reason for the remote not being optional, or are we just\n>> waiting for a patch? The only problem I can foresee is very minor:\n>> there is a ref with the same name as a remote; in this case, we'd have\n>> to specify both the remote and the ref.\n>\n> I think the ambiguity is a little more complex than that, because we\n> cannot enumerate the universe of all remotes. Keep in mind that we can\n> take either a configured remote or a URL (or ssh host). So what does:\n>\n> git push foo:bar\n>\n> mean? Is it pushing \"refs/heads/foo\" to \"refs/heads/bar\" on \"origin\"? Or\n> is it using the default refspecs to push to the \"bar\" repo on the host\n> \"foo\" over ssh?\n\nWait, why does git-push support pushing to a URL directly? Shouldn't\nthe user be required to create a new remote out of the URL and push to\nthat? What happens to upstream branches if we directly push to a URL?\n"},{"id":"211647","messageId":"20130319100232.GA6120@sigill.intra.peff.net","threadId":"33218","inReplyTo":"CALkWK0=WCsXErHft9RbDOeehon7E2oCj5-YT6Ph+8bLFW-5JaQ@mail.gmail.com","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-03-19T10:02:32Z","receivedAt":"2013-03-19T10:02:32Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Mar 19, 2013 at 03:28:12PM +0530, Ramkumar Ramachandra wrote:\n\n> > I think the ambiguity is a little more complex than that, because we\n> > cannot enumerate the universe of all remotes. Keep in mind that we can\n> > take either a configured remote or a URL (or ssh host). So what does:\n> >\n> > git push foo:bar\n> >\n> > mean? Is it pushing \"refs/heads/foo\" to \"refs/heads/bar\" on \"origin\"? Or\n> > is it using the default refspecs to push to the \"bar\" repo on the host\n> > \"foo\" over ssh?\n> \n> Wait, why does git-push support pushing to a URL directly? Shouldn't\n> the user be required to create a new remote out of the URL and push to\n> that? What happens to upstream branches if we directly push to a URL?\n\nI do not recall the exact history, but I would not be surprised if git\nfirst learned to push to a URL, and later learned about configured\nremotes. I do not use it that often myself these days, but I find it\noccasionally useful for one-off pushes (e.g., pushing a normally private\nrepo to a temporary publishing point to share with somebody else).\n\nIn that case, upstream branches are not touched at all (because we do\nnot have a configured remote whose fetch refspec we can examine).\n\n-Peff\n"},{"id":"211659","messageId":"CACsJy8Ad7rKtMd-6BoBtbVa70F0AaJ+OUjEykNh344tPw7F7Vg@mail.gmail.com","threadId":"33218","inReplyTo":"20130318170804.GA15924@sigill.intra.peff.net","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2013-03-19T11:33:12Z","receivedAt":"2013-03-19T11:33:12Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Mar 19, 2013 at 12:08 AM, Jeff King wrote:\n>> Is there a reason for the remote not being optional, or are we just\n>> waiting for a patch? The only problem I can foresee is very minor:\n>> there is a ref with the same name as a remote; in this case, we'd have\n>> to specify both the remote and the ref.\n>\n> I think the ambiguity is a little more complex than that, because we\n> cannot enumerate the universe of all remotes. Keep in mind that we can\n> take either a configured remote or a URL (or ssh host). So what does:\n>\n> git push foo:bar\n>\n> mean? Is it pushing \"refs/heads/foo\" to \"refs/heads/bar\" on \"origin\"? Or\n> is it using the default refspecs to push to the \"bar\" repo on the host\n> \"foo\" over ssh?\n>\n> So you would need some heuristics based on whether something was a valid\n> refspec, or could be a valid remote name or URL.\n\nAssume that we agree on what remote is implied, we could simplify\nparsing by specifying the remote with \".\" (or something short and\nunambiguous). So the above command would become\n\ngit push . foo:bar\n\nNot too much to type\n-- \nDuy\n"},{"id":"211660","messageId":"CALkWK0nhmks6LqoALA8hrwkR00NjweyqV2RJ9-9V3q-bjgpsCg@mail.gmail.com","threadId":"33218","inReplyTo":"CACsJy8Ad7rKtMd-6BoBtbVa70F0AaJ+OUjEykNh344tPw7F7Vg@mail.gmail.com","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-03-19T11:53:36Z","receivedAt":"2013-03-19T11:53:36Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Duy Nguyen wrote:\n> On Tue, Mar 19, 2013 at 12:08 AM, Jeff King wrote:\n>>> Is there a reason for the remote not being optional, or are we just\n>>> waiting for a patch? The only problem I can foresee is very minor:\n>>> there is a ref with the same name as a remote; in this case, we'd have\n>>> to specify both the remote and the ref.\n>>\n>> I think the ambiguity is a little more complex than that, because we\n>> cannot enumerate the universe of all remotes. Keep in mind that we can\n>> take either a configured remote or a URL (or ssh host). So what does:\n>>\n>> git push foo:bar\n>>\n>> mean? Is it pushing \"refs/heads/foo\" to \"refs/heads/bar\" on \"origin\"? Or\n>> is it using the default refspecs to push to the \"bar\" repo on the host\n>> \"foo\" over ssh?\n>>\n>> So you would need some heuristics based on whether something was a valid\n>> refspec, or could be a valid remote name or URL.\n>\n> Assume that we agree on what remote is implied, we could simplify\n> parsing by specifying the remote with \".\" (or something short and\n> unambiguous). So the above command would become\n>\n> git push . foo:bar\n\nA URL may be a path to a git repository, and '.' is a valid path.\nCurrently, 'git push .' seems to push to the current repository (what\ndoes that even mean?). For something truly unambiguous, we'll have to\nuse a character that's disallowed in URLs and isn't interpreted by the\nshell- I can't seem to think of one. Otherwise, we'll have to\nfallback to using heuristics anyway.\n"},{"id":"211661","messageId":"514852D7.9080607@ira.uka.de","threadId":"33218","inReplyTo":"CACsJy8Ad7rKtMd-6BoBtbVa70F0AaJ+OUjEykNh344tPw7F7Vg@mail.gmail.com","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Holger Hellmuth (IKS)","fromEmail":"hellmuth@ira.uka.de","sentAt":"2013-03-19T11:58:15Z","receivedAt":"2013-03-19T11:58:15Z","isPatch":false,"sender":{"key":"hellmuth@ira.uka.de","avatar":null},"body":"Am 19.03.2013 12:33, schrieb Duy Nguyen:\n> git push . foo:bar\n\n'.' has more like a \"here\" semantic, '..' might be a more fitting \nmnemonic here.\n"},{"id":"211662","messageId":"CACsJy8D10yXoxynOscWjCyAq8qxeXOCMJLqkFYzSRUokUgYF8A@mail.gmail.com","threadId":"33218","inReplyTo":"CALkWK0nhmks6LqoALA8hrwkR00NjweyqV2RJ9-9V3q-bjgpsCg@mail.gmail.com","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2013-03-19T12:15:19Z","receivedAt":"2013-03-19T12:15:19Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Mar 19, 2013 at 6:53 PM, Ramkumar Ramachandra\n wrote:\n>> git push . foo:bar\n>\n> A URL may be a path to a git repository, and '.' is a valid path.\n> Currently, 'git push .' seems to push to the current repository (what\n> does that even mean?). For something truly unambiguous, we'll have to\n> use a character that's disallowed in URLs and isn't interpreted by the\n> shell- I can't seem to think of one. Otherwise, we'll have to\n> fallback to using heuristics anyway.\n\nYeah that was a stupid suggestion. There's also \"-\". Right now git\npush accepts it as a remote name, but I think in general \"-\" alone has\nalways had a special meaning in UNIX world. We could put a new meaning\nto it (literal \"-\" directory can be specified with \"./-\"). Not totally\nsure if \"-\" is allowed in refspec though.\n-- \nDuy\n"},{"id":"211665","messageId":"51486226.90203@ira.uka.de","threadId":"33218","inReplyTo":"CACsJy8D10yXoxynOscWjCyAq8qxeXOCMJLqkFYzSRUokUgYF8A@mail.gmail.com","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Holger Hellmuth (IKS)","fromEmail":"hellmuth@ira.uka.de","sentAt":"2013-03-19T13:03:34Z","receivedAt":"2013-03-19T13:03:34Z","isPatch":false,"sender":{"key":"hellmuth@ira.uka.de","avatar":null},"body":"Would it make sense to allow abbreviation similar to how git objects can \nbe abbreviated? This would mean origin usually could be spelled just o\n"},{"id":"211678","messageId":"7v1ubbl7jn.fsf@alter.siamese.dyndns.org","threadId":"33218","inReplyTo":"CACsJy8Ad7rKtMd-6BoBtbVa70F0AaJ+OUjEykNh344tPw7F7Vg@mail.gmail.com","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-03-19T15:43:08Z","receivedAt":"2013-03-19T15:43:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Duy Nguyen writes:\n\n> Assume that we agree on what remote is implied, we could simplify\n> parsing by specifying the remote with \".\" (or something short and\n> unambiguous). So the above command would become\n>\n> git push . foo:bar\n\nThat is an established idiom, a handy way to update your own bar\nbranch to commit pointed by foo branch when and only when the update\nfast-forwards.\n\nPlease don't.\n"},{"id":"211679","messageId":"7vwqt3jsxv.fsf@alter.siamese.dyndns.org","threadId":"33218","inReplyTo":"514852D7.9080607@ira.uka.de","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-03-19T15:43:56Z","receivedAt":"2013-03-19T15:43:56Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Holger Hellmuth (IKS)\" writes:\n\n> Am 19.03.2013 12:33, schrieb Duy Nguyen:\n>> git push . foo:bar\n>\n> '.' has more like a \"here\" semantic, '..' might be a more fitting\n> mnemonic here.\n\nHeh, why not say \"origin\"? Or rename it to \"o\" if you like in your\nown repository ;-)\n"},{"id":"213651","messageId":"CALkWK0k2a6DSUodhKjRFKGvE1Rb_QmFgpy=Pvbu2Q=nGNYuByA@mail.gmail.com","threadId":"33218","inReplyTo":"20130318170804.GA15924@sigill.intra.peff.net","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-09T11:44:27Z","receivedAt":"2013-04-09T11:44:27Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Jeff King wrote:\n> So you would need some heuristics based on whether something was a valid\n> refspec, or could be a valid remote name or URL.\n\nAll refspecs conform to a very simple format:\n\n quux\n +quux\n quux:baz\n +quux:baz\n\nAll of them fail at git_connect(). The third and fourth are\nequivalent and take a little longer to fail than the first two,\nbecause ssh tries to resolve the hostname \"quux\" or \"+quux\".\n\nOkay, so I was hoping that we could first attempt to push as usual,\nand fallback to pushing with the refspec set to argv[0] (if argc is\n1); this approach is foolproof and doesn't involve any guessing.\nUnfortunately, it's going to be very hard, as the callstack to the\nfinal git_connect() failure looks like:\n\n git_connect()\n connect_setup()\n get_refs_via_connect()\n transport_push()\n push_with_options()\n do_push()\n\nNow, it's nearly impossible to propagate the error back from\ngit_connect() to do_push() and switch the refspec. It's not a simple\ncallstack either: there are callbacks being setup and called.\n\nThere's one small consolation in all this: all refspecs are match\nmatch the !is_url() condition in transport.c:939 get_transport(), and\nno preceding conditions. This means that there is one place to check\nif it could possibly be a ref, that's not very deep in the callstack,\nand return something to the caller appropriately. Currently,\nget_transport() always returns a valid struct transport with no extra\ninformation; maybe we can change this?\n\nDuy's approach of using a special \"-\" is trivial to implement, but\ndoesn't make me happy. There's no reason I can't have 'git push\nmaster +pu foo:bar'.\n\nThoughts?\n"},{"id":"213679","messageId":"7vzjx7sj9u.fsf@alter.siamese.dyndns.org","threadId":"33218","inReplyTo":"CALkWK0k2a6DSUodhKjRFKGvE1Rb_QmFgpy=Pvbu2Q=nGNYuByA@mail.gmail.com","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-09T17:31:25Z","receivedAt":"2013-04-09T17:31:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra writes:\n\n> Jeff King wrote:\n>> So you would need some heuristics based on whether something was a valid\n>> refspec, or could be a valid remote name or URL.\n>\n> All refspecs conform to a very simple format:\n>\n> quux\n> +quux\n> quux:baz\n> +quux:baz\n>\n> All of them fail at git_connect(). The third and fourth are\n> equivalent and take a little longer to fail than the first two,\n> because ssh tries to resolve the hostname \"quux\" or \"+quux\".\n\nhost:foo/bar (take my \"host\" branch, push it to their \"foo/bar\"\nbranch) could be tricky, no? It could be trying to go over the ssh\nto \"host\" and access repository at $HOME/foo/bar. The git_connect()\ncall may even succeed and you cannot use the failure as a hint to\ndisambiguate.\n\nAlso the request may genuinely be to access foo/bar repository at\nthe host, but the network layer had trouble connecting temporarily\nto the host. After disambiguating incorrectly to push to the\norigin, mapping our host branch to their foo/bar branch, that push\nmight even succeed.\n"},{"id":"213681","messageId":"CALkWK0=siuUW1ex0muy+efwQOAwHf3uorFHWPo5sjMss08ywiw@mail.gmail.com","threadId":"33218","inReplyTo":"7vzjx7sj9u.fsf@alter.siamese.dyndns.org","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-09T17:39:20Z","receivedAt":"2013-04-09T17:39:20Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n> host:foo/bar (take my \"host\" branch, push it to their \"foo/bar\"\n> branch) could be tricky, no? It could be trying to go over the ssh\n> to \"host\" and access repository at $HOME/foo/bar. The git_connect()\n> call may even succeed and you cannot use the failure as a hint to\n> disambiguate.\n>\n> Also the request may genuinely be to access foo/bar repository at\n> the host, but the network layer had trouble connecting temporarily\n> to the host. After disambiguating incorrectly to push to the\n> origin, mapping our host branch to their foo/bar branch, that push\n> might even succeed.\n\nOh, ouch. I didn't think of that. What do you suggest we do? Go\nwith Duy's simple '-' solution, or try some heuristics that may lead\nto confusing behavior in edge cases?\n"},{"id":"213689","messageId":"7vip3vsi19.fsf@alter.siamese.dyndns.org","threadId":"33218","inReplyTo":"CALkWK0=siuUW1ex0muy+efwQOAwHf3uorFHWPo5sjMss08ywiw@mail.gmail.com","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-09T17:58:10Z","receivedAt":"2013-04-09T17:58:10Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra writes:\n\n> Junio C Hamano wrote:\n>> host:foo/bar (take my \"host\" branch, push it to their \"foo/bar\"\n>> branch) could be tricky, no? It could be trying to go over the ssh\n>> to \"host\" and access repository at $HOME/foo/bar. The git_connect()\n>> call may even succeed and you cannot use the failure as a hint to\n>> disambiguate.\n>>\n>> Also the request may genuinely be to access foo/bar repository at\n>> the host, but the network layer had trouble connecting temporarily\n>> to the host. After disambiguating incorrectly to push to the\n>> origin, mapping our host branch to their foo/bar branch, that push\n>> might even succeed.\n>\n> Oh, ouch. I didn't think of that. What do you suggest we do? Go\n> with Duy's simple '-' solution, or try some heuristics that may lead\n> to confusing behavior in edge cases?\n\nWhat is bad about saying \"push origin ...the rest...\"?\n\nIt is beyond me why people would want to invent unintuitive line\nnoise like '-' that others need to read the manual from cover to\ncover to find and memorize for something small like this.\n"},{"id":"213691","messageId":"CALkWK0nqZ+GGvDhR=OPOz+NtYKXz7waQrxvCi-spAJ46pL=YKA@mail.gmail.com","threadId":"33218","inReplyTo":"7vip3vsi19.fsf@alter.siamese.dyndns.org","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-09T18:03:59Z","receivedAt":"2013-04-09T18:03:59Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n> What is bad about saying \"push origin ...the rest...\"?\n\nI don't know which remote to push to: all I know is that the remote to\npush to is configured somewhere in the web of branch.remote,\nremote.pushdefault, and branch..pushremote, and I don't want to\nhave to figure that out by hand. Ever since we got triangular\nworkflows, I've been missing the implicit beauty when I have to\nforce-push some refs.\n"},{"id":"213693","messageId":"CALkWK0=tHitdEsC8OLrhhjvL+1NoPDHtLAOEbn3MqBLG5wcbow@mail.gmail.com","threadId":"33218","inReplyTo":"CALkWK0nqZ+GGvDhR=OPOz+NtYKXz7waQrxvCi-spAJ46pL=YKA@mail.gmail.com","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-09T18:08:44Z","receivedAt":"2013-04-09T18:08:44Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Ramkumar Ramachandra wrote:\n> [...]\n\nLet's not do anything too complex, and just aim for a more pleasant\nexperience for the simple case of force-pushing some refs without the\n: counterpart. Then, all we have to do is verify that what is\nspecified is not a valid remote, and is not a valid local path (to a\ngit repository, but we don't need to check that), correct?\n"},{"id":"213707","messageId":"7vhajfqz8r.fsf@alter.siamese.dyndns.org","threadId":"33218","inReplyTo":"CALkWK0nqZ+GGvDhR=OPOz+NtYKXz7waQrxvCi-spAJ46pL=YKA@mail.gmail.com","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-09T19:29:24Z","receivedAt":"2013-04-09T19:29:24Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra writes:\n\n> Junio C Hamano wrote:\n>> What is bad about saying \"push origin ...the rest...\"?\n>\n> I don't know which remote to push to: all I know is that the remote to\n> push to is configured somewhere in the web of ...\n\nAhh, and then the recent triangular stuff makes it even worse.\n\nI can see why we might want some token that says \"I am pushing where\nI would push normally if this were a 'git push' that does not say\n'to where' and 'push what'\" to help users.\n\nSome background to explain why I was hesitant to the change.\n\nThere must be a reason why the user wants to use a custom set of\nrefspecs, not the configured ones, for this particular push only.\nThere must be something special for this particular push that makes\nit different from the configured 'git push' default.\n\nI was wondering if it is sensible to assume that the user is likely\nto still want to push to the same repository where she usually\npushes to, when she has that special reason. The underlying\nassumption for it to be sensible is that 'to where' (destination\nrepository) is more sticky than 'push what' (the refspecs).\n\nAnd I think now I agree that indeed is a sensible assumption. I am\nnot sure '-' is a good token for that, but I do not offhand think of\na reason why '-' would be a _bad_ token for that, either.\n"},{"id":"213736","messageId":"20130409231332.GZ30308@google.com","threadId":"33218","inReplyTo":"7vhajfqz8r.fsf@alter.siamese.dyndns.org","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-04-09T23:13:32Z","receivedAt":"2013-04-09T23:13:32Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Junio C Hamano wrote:\n\n> And I think now I agree that indeed is a sensible assumption. I am\n> not sure '-' is a good token for that, but I do not offhand think of\n> a reason why '-' would be a _bad_ token for that, either.\n\nRandom idea: today you can do\n\n\tgit push origin master; # push branch master to remote origin\n\tgit push --multiple origin korg; # push default refspec to 2 remotes\n\nHow about:\n\n\tgit push origin korg -- master; # push master to 2 remotes\n\tgit push -- master next; # push two refs to default remote\n\tgit push origin -- master; # push master to origin, more explicitly\n\tgit push origin korg --; # push default refspec to 2 remotes, again\n\n\tgit push host:some/path; # ambiguous argument. Please disambiguate.\n\tgit push host:some/path --; # push default refspec over SSH\n\tgit push -- host:some/path; # push specified refspec to default remote\n\n\tgit push origin; # is a remote name and not a refname. Good.\n\tgit push master; # is a ref name and not a remote name. Good.\n\nWhat do you think?\nJonathan\n"},{"id":"213737","messageId":"20130409231421.GA30308@google.com","threadId":"33218","inReplyTo":"20130409231332.GZ30308@google.com","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-04-09T23:14:21Z","receivedAt":"2013-04-09T23:14:21Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Jonathan Nieder wrote:\n\n> today you can do\n>\n> \tgit push origin master; # push branch master to remote origin\n> \tgit push --multiple origin korg; # push default refspec to 2 remotes\n\nPretend I said \"fetch\". ;-)\n"},{"id":"213740","messageId":"7vobdnnpx6.fsf@alter.siamese.dyndns.org","threadId":"33218","inReplyTo":"20130409231332.GZ30308@google.com","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-10T01:19:01Z","receivedAt":"2013-04-10T01:19:01Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder writes:\n\n> Junio C Hamano wrote:\n>\n>> And I think now I agree that indeed is a sensible assumption. I am\n>> not sure '-' is a good token for that, but I do not offhand think of\n>> a reason why '-' would be a _bad_ token for that, either.\n>\n> Random idea: today you can do\n>\n> \tgit push origin master; # push branch master to remote origin\n> \tgit push --multiple origin korg; # push default refspec to 2 remotes\n>\n> How about:\n>\n> \tgit push origin korg -- master; # push master to 2 remotes\n\nFor this to be any useful, origin and korg has to have the same or\nat least similar ref structure, such that pushing my 'master' to\ntheir 'master' makes sense for both sites. I am not sure how common\nit would be. If people commonly do so, the above looks like a\nreasonably useful feature.\n\n> \tgit push -- master next; # push two refs to default remote\n\n... or default \"push remote\" if there is one, I presume?\n\nAs you are giving what to push, I am assuming that\nbranch.$name.remote would not come into play in this case.\n\n> \tgit push origin -- master; # push master to origin, more explicitly\n\n\n> \tgit push origin korg --; # push default refspec to 2 remotes, again\n\nAs you are _not_ saying what to push, I would expect\nbranch.$name.remote may have to come into the picture, but because\nyou are saying where to push, that is not the case. What does\n\"default refspec\" mean in this context? What \"git push origin\" (no refspecs)\nwould push by default will be sent to \"origin\", and what \"git push\nkorg\" (no refspecs) would push by default will be sent to \"korg\"?\n\nAll of the above sounds a bit too complicated to explain to end\nusers, but I think they are internally consistent.\n\n> \tgit push host:some/path; # ambiguous argument. Please disambiguate.\n> \tgit push host:some/path --; # push default refspec over SSH\n> \tgit push -- host:some/path; # push specified refspec to default remote\n\nOK.\n\n> \tgit push origin; # is a remote name and not a refname. Good.\n> \tgit push master; # is a ref name and not a remote name. Good.\n\nHmm, I dunno.\n\n> What do you think?\n> Jonathan\n"},{"id":"213741","messageId":"20130410035039.GA795@sigill.intra.peff.net","threadId":"33218","inReplyTo":"20130409231332.GZ30308@google.com","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-04-10T03:50:39Z","receivedAt":"2013-04-10T03:50:39Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Apr 09, 2013 at 04:13:32PM -0700, Jonathan Nieder wrote:\n\n> Random idea: today you can do\n> \n> \tgit push origin master; # push branch master to remote origin\n> \tgit push --multiple origin korg; # push default refspec to 2 remotes\n\nCan we do \"git push --multiple\" today? My git does not seem to know\nabout that (and I don't remember any patches in the area). Am I missing\nsomething?\n\n> How about:\n> \n> \tgit push origin korg -- master; # push master to 2 remotes\n> \tgit push -- master next; # push two refs to default remote\n> \tgit push origin -- master; # push master to origin, more explicitly\n> \tgit push origin korg --; # push default refspec to 2 remotes, again\n\nI like that _way_ better than the \"-\" proposal. Rather than introducing\na magic token for \"the default ref\", it fixes the actual syntax problem\n(that we have two lists of arguments to the command, and we do not know\nwhere one begins and the other ends). And it does it the same way as\nother parts of git.\n\n> \tgit push host:some/path; # ambiguous argument. Please disambiguate.\n\nThis is a regression. I thought the point of this exercise was to leave\nthat working. We could just as easily switch to:\n\n git push --remote=host:some/path\n\nif we are willing to break the existing syntax. Though your proposal\ndoes have the benefit of breaking only one particular syntax which is\n(I'm guessing) less frequently used. But we'd still need the usual\ndeprecation period, I think.\n\n> \tgit push host:some/path --; # push default refspec over SSH\n> \tgit push -- host:some/path; # push specified refspec to default remote\n\nI like this.\n\n> \tgit push origin; # is a remote name and not a refname. Good.\n> \tgit push master; # is a ref name and not a remote name. Good.\n\nAnd this is sensible, too.\n\n-Peff\n"},{"id":"213742","messageId":"20130410041343.GB795@sigill.intra.peff.net","threadId":"33218","inReplyTo":"7vobdnnpx6.fsf@alter.siamese.dyndns.org","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-04-10T04:13:43Z","receivedAt":"2013-04-10T04:13:43Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Apr 09, 2013 at 06:19:01PM -0700, Junio C Hamano wrote:\n\n> > \tgit push -- master next; # push two refs to default remote\n> \n> ... or default \"push remote\" if there is one, I presume?\n> \n> As you are giving what to push, I am assuming that\n> branch.$name.remote would not come into play in this case.\n\nI would have assumed the opposite. We feed \"push\" two items: where to\npush (dst), and what refspecs to push (refs). We may or may not have\neach item. Here's what's possible today:\n\n dst=present, refs=present: (case 1)\n push to $dst, using $refs\n dst=present, refs=missing: (case 2)\n push to $dst, using refspecs from remote.$dst.push or push.default\n dst=missing, refs=missing: (case 3)\n push to remote.pushDefault, branch.*.remote, or \"origin\"; use\n refspecs from remote.$x.push or push.default, where $x is the remote\n we decide to use.\n\nThe missing case 4 is obviously:\n\n dst=missing, refs=present\n\nAnd I would expect it to select the remote in the same way as case 3. In\nother words, the \"where\" and the \"what\" are orthogonal, and the presence\nor absence of one does not affect how the other is calculated (with the\nexception that _if_ we have a configured remote, whether it was\nspecified by the user or calculated, we may use its config if no\nrefspecs are specified).\n\nDo you want to explain your thinking? I'm guessing it has to do with the\nfact that choosing branch.*.remote is about trying to push to the\nconfigured upstream (even though we traditionally do _not_ take into\naccount branch.*.merge when doing so).\n\n> > \tgit push origin korg --; # push default refspec to 2 remotes, again\n> \n> As you are _not_ saying what to push, I would expect\n> branch.$name.remote may have to come into the picture, but because\n> you are saying where to push, that is not the case. What does\n> \"default refspec\" mean in this context? What \"git push origin\" (no refspecs)\n> would push by default will be sent to \"origin\", and what \"git push\n> korg\" (no refspecs) would push by default will be sent to \"korg\"?\n\nYeah, I would expect that each uses its own default refspec. That is,\nthe above command is exactly equivalent to:\n\n git push origin && git push korg\n\n(possibly without the short-circuit behavior of \"&&\", but definitely\ntaking both into account in the exit code).\n\nI'd also be fine if we punted on the multiple remotes thing for now. You\ncan accomplish it easily in the shell, as I showed above (and it is not\nany less efficient, since we have to make two network connections\nanyway). Jonathan's syntax allows for 0 to N remotes alongside 0 to N\nrefspecs. The interesting new case (to me, anyway) is the 0 remotes, >0\nrefspecs case. But we don't have to handle >1 remotes now; once we have\nthe syntax in place, we can make it work later when we've decided on the\nsemantics.\n\n-Peff\n"},{"id":"213770","messageId":"CALkWK0=St08WGD82JqGpW7ZVrtv0RU8=X9kUqzYb+6Jm8X63aw@mail.gmail.com","threadId":"33218","inReplyTo":"20130409231332.GZ30308@google.com","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-10T13:19:14Z","receivedAt":"2013-04-10T13:19:14Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Jonathan Nieder wrote:\n> git push origin korg -- master; # push master to 2 remotes\n> git push -- master next; # push two refs to default remote\n> git push origin -- master; # push master to origin, more explicitly\n> git push origin korg --; # push default refspec to 2 remotes, again\n\nI definitely like the idea of using -- to disambiguate, as it is\nconsistent with existing git commands (that are internally using the\nrev-list machinery). However, I disagree with the idea of being able\nto specify multiple remotes: what does 'git push A B -- master +next'\nmean? Do I know that master and next are present in both A and B? Do\nI know for certain that a force-push to next won't wipe any data on\neither A or B accidentally? As the number of remotes and refs\nincrease, the amount of information that the user must know about each\nof the remotes is simply huge. Therefore, I think it is unnecessarily\nconfusing and unnecessary. Moreover, it can easily be achieved in\nshell, and there is no advantage to supporting it in push unless we're\ndoing something like a parallel push.\n\n> git push host:some/path; # ambiguous argument. Please disambiguate.\n\nRegression. It should just treat host:some/path as a destination, not a ref.\n\n> git push origin; # is a remote name and not a refname. Good.\n> git push master; # is a ref name and not a remote name. Good.\n\nThis is what I finally want. With your -- to disambiguate, the logic\nfor doing this has been simplified greatly.\n"},{"id":"213771","messageId":"CALkWK0=Tu7ttVqF1RPKvHiMQTH7dU+PKCfsZw9eq1H=vkRen9A@mail.gmail.com","threadId":"33218","inReplyTo":"20130410035039.GA795@sigill.intra.peff.net","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-10T13:22:51Z","receivedAt":"2013-04-10T13:22:51Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Jeff King wrote:\n> git push --remote=host:some/path\n>\n> if we are willing to break the existing syntax. Though your proposal\n> does have the benefit of breaking only one particular syntax which is\n> (I'm guessing) less frequently used. But we'd still need the usual\n> deprecation period, I think.\n\nWhy? 'git push host:some/path' should treat host:some/path as a\ndestination and not a refspec. If the user meant refspec, she should\ndo 'git push -- host:some/path' instead.\n"},{"id":"213780","messageId":"20130410155611.GA10749@sigill.intra.peff.net","threadId":"33218","inReplyTo":"CALkWK0=Tu7ttVqF1RPKvHiMQTH7dU+PKCfsZw9eq1H=vkRen9A@mail.gmail.com","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-04-10T15:56:11Z","receivedAt":"2013-04-10T15:56:11Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Apr 10, 2013 at 06:52:51PM +0530, Ramkumar Ramachandra wrote:\n\n> Jeff King wrote:\n> > git push --remote=host:some/path\n> >\n> > if we are willing to break the existing syntax. Though your proposal\n> > does have the benefit of breaking only one particular syntax which is\n> > (I'm guessing) less frequently used. But we'd still need the usual\n> > deprecation period, I think.\n> \n> Why? 'git push host:some/path' should treat host:some/path as a\n> destination and not a refspec. If the user meant refspec, she should\n> do 'git push -- host:some/path' instead.\n\nYou snipped the part of Jonathan's message I quoted; I was responding\nspecifically to making \"git push host:some/path\" an error. I do not\nthink that is a good idea, and doing so would require a deprecation\nperiod.\n\n-Peff\n"},{"id":"213784","messageId":"7v4nfenxzm.fsf@alter.siamese.dyndns.org","threadId":"33218","inReplyTo":"20130410041343.GB795@sigill.intra.peff.net","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-10T16:37:01Z","receivedAt":"2013-04-10T16:37:01Z","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 09, 2013 at 06:19:01PM -0700, Junio C Hamano wrote:\n>\n>> > \tgit push -- master next; # push two refs to default remote\n>> \n>> ... or default \"push remote\" if there is one, I presume?\n>> \n>> As you are giving what to push, I am assuming that\n>> branch.$name.remote would not come into play in this case.\n>\n>...\n> The missing case 4 is obviously:\n>\n> dst=missing, refs=present\n> ...\n> Do you want to explain your thinking? I'm guessing it has to do with the\n> fact that choosing branch.*.remote is about trying to push to the\n> configured upstream (even though we traditionally do _not_ take into\n> account branch.*.merge when doing so).\n\nWith the branch.$name.remote, the user tells us \"When I am on this\nbranch, I want to talk to this remote\". When you did\n\n\tgit push -- master next ;# case #4\n\non branch maint, branch.maint.remote should not come into play.\n\nWould we want to push our 'master' to branch.master.remote in a way \n\n\tgit checkout master && git push\n\nwould do, while at the same time because we were told to do the same\nfor 'next', we do the same as\n\n\tgit checkout next && git push\n\nwould do? That would work if you give just branch names, but that\nis not a general enough definition to cover your case #4, e.g.\n\n\tgit push -- v1.2.3 master:refs/remotes/mothership/master\n\nIf we define case #4 to push to the remote.pushdefault (falling back\nto remote.default), this case would do what can simply be expected;\nif the earlier cases also push to that same place, ignoring\nbranch.$name.remote for master and next, that would be consistent.\n"},{"id":"213785","messageId":"7vzjx6mjct.fsf@alter.siamese.dyndns.org","threadId":"33218","inReplyTo":"20130410035039.GA795@sigill.intra.peff.net","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-10T16:38:26Z","receivedAt":"2013-04-10T16:38:26Z","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 09, 2013 at 04:13:32PM -0700, Jonathan Nieder wrote:\n>\n>> Random idea: today you can do\n>> \n>> \tgit push origin master; # push branch master to remote origin\n>> \tgit push --multiple origin korg; # push default refspec to 2 remotes\n>\n> Can we do \"git push --multiple\" today?\n\nYou can have multiple destination URLs for a single remote nickname.\nWouldn't that be sufficient for regular publishing purposes?\n"},{"id":"213789","messageId":"20130410172748.GA16908@sigill.intra.peff.net","threadId":"33218","inReplyTo":"7v4nfenxzm.fsf@alter.siamese.dyndns.org","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-04-10T17:27:48Z","receivedAt":"2013-04-10T17:27:48Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Apr 10, 2013 at 09:37:01AM -0700, Junio C Hamano wrote:\n\n> > The missing case 4 is obviously:\n> >\n> > dst=missing, refs=present\n> > ...\n> > Do you want to explain your thinking? I'm guessing it has to do with the\n> > fact that choosing branch.*.remote is about trying to push to the\n> > configured upstream (even though we traditionally do _not_ take into\n> > account branch.*.merge when doing so).\n> \n> With the branch.$name.remote, the user tells us \"When I am on this\n> branch, I want to talk to this remote\". When you did\n> \n> \tgit push -- master next ;# case #4\n> \n> on branch maint, branch.maint.remote should not come into play.\n\nI understand that's your position, but I don't understand _why_.\n\nIf branch.$name.remote is \"when I am on this branch, I want to talk to\nthis remote\", that rule is not be impacted by the presence of refspecs\nat all.\n\nIf it meant \"when I am on this branch, and I do not specify any\nrefspecs, then I would by default want to push this branch to that\nremote\", then your proposed behavior would make more sense. And if you\nare using push.default=upstream, that is what happens.\n\nBut historically the default push has been \"matching\". So in your other\nexamples:\n\n> Would we want to push our 'master' to branch.master.remote in a way \n> \n> \tgit checkout master && git push\n> \n> would do, while at the same time because we were told to do the same\n> for 'next', we do the same as\n> \n> \tgit checkout next && git push\n\nThese do not have anything to do with pushing the checked-out branch in\nparticular. The first one may very well be pushing \"next\" to the remote\nspecified by branch.master.remote.\n\nSo I would argue that one of these two makes sense:\n\n 1. branch.*.remote means \"use this as the default remote on this\n branch, no matte which refs we are pushing\"\n\n 2. branch.*.remote is not respected at all for remote selection with\n \"matching\". It is used only when combined with branch.*.merge,\n which means that only the \"upstream\" mode would use it.\n\nI advocated (1) in my previous message, but I would also be OK with (2),\neven though it is a change from the current behavior. But what you are\nsuggesting seems like an inconsistent mix of the two.\n\n> would do? That would work if you give just branch names, but that\n> is not a general enough definition to cover your case #4, e.g.\n> \n> \tgit push -- v1.2.3 master:refs/remotes/mothership/master\n> \n> If we define case #4 to push to the remote.pushdefault (falling back\n> to remote.default), this case would do what can simply be expected;\n> if the earlier cases also push to that same place, ignoring\n> branch.$name.remote for master and next, that would be consistent.\n\nSo I think what you are getting at is that branch.*.remote is about\nsaying \"when we push X, it goes to remote Y\". And with v1.2.3, we\nobviously cannot have such a hint, because it is not a branch. But my\npoint is that is _not_ how it works today. So if you want consistency,\nwe would also need to adjust how branch.*.remote interacts with\n\"matching\".\n\n-Peff\n"},{"id":"213790","messageId":"20130410172914.GB16908@sigill.intra.peff.net","threadId":"33218","inReplyTo":"7vzjx6mjct.fsf@alter.siamese.dyndns.org","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-04-10T17:29:14Z","receivedAt":"2013-04-10T17:29:14Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Apr 10, 2013 at 09:38:26AM -0700, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > On Tue, Apr 09, 2013 at 04:13:32PM -0700, Jonathan Nieder wrote:\n> >\n> >> Random idea: today you can do\n> >> \n> >> \tgit push origin master; # push branch master to remote origin\n> >> \tgit push --multiple origin korg; # push default refspec to 2 remotes\n> >\n> > Can we do \"git push --multiple\" today?\n> \n> You can have multiple destination URLs for a single remote nickname.\n> Wouldn't that be sufficient for regular publishing purposes?\n\nYes, though that is different than specifying two different remotes,\nwhich may have their own sets of default refspecs (i.e., what Jonathan\nwrote above). If they are two URLs of the same configured remote, there\nis no question that they should respect the same refspecs.\n\n-Peff\n"},{"id":"213802","messageId":"7vhajemd1x.fsf@alter.siamese.dyndns.org","threadId":"33218","inReplyTo":"20130410172748.GA16908@sigill.intra.peff.net","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-10T18:54:34Z","receivedAt":"2013-04-10T18:54:34Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n>> With the branch.$name.remote, the user tells us \"When I am on this\n>> branch, I want to talk to this remote\". When you did\n>> \n>> \tgit push -- master next ;# case #4\n>> \n>> on branch maint, branch.maint.remote should not come into play.\n>\n> I understand that's your position, but I don't understand _why_.\n>\n> If branch.$name.remote is \"when I am on this branch, I want to talk to\n> this remote\", that rule is not be impacted by the presence of refspecs\n> at all.\n\nSo running the above while on 'maint' will send master and next to\nthe remote your \"git push\" would send to when run without any\nrefspecs?\n\nThat is internally consistent and understandable, and I have no\nobjection to it. Certainly much better than basing the decision on\nbranch.{master,next}.remote as I thought you were suggesting to do.\n"},{"id":"213805","messageId":"20130410185958.GA22394@sigill.intra.peff.net","threadId":"33218","inReplyTo":"7vhajemd1x.fsf@alter.siamese.dyndns.org","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-04-10T18:59:58Z","receivedAt":"2013-04-10T18:59:58Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Apr 10, 2013 at 11:54:34AM -0700, Junio C Hamano wrote:\n\n> > If branch.$name.remote is \"when I am on this branch, I want to talk to\n> > this remote\", that rule is not be impacted by the presence of refspecs\n> > at all.\n> \n> So running the above while on 'maint' will send master and next to\n> the remote your \"git push\" would send to when run without any\n> refspecs?\n\nExactly. The remote selection is orthogonal to the refspecs provided,\nand only cares about which branch you are on.\n\nWhich is still kind of weird, because why should the branch you are on\naffect the default push location? But that is how default \"matching\" has\nalways behaved, and we would remain consistent with that.\n\n> That is internally consistent and understandable, and I have no\n> objection to it. Certainly much better than basing the decision on\n> branch.{master,next}.remote as I thought you were suggesting to do.\n\nNo, I am not suggesting that. I can see how such a command might be\nuseful (i.e. \"push master to where it goes, next to where it goes\",\nwhere \"goes\" is defined by the upstream config). But that is not\nremotely close to how \"git push\" works now, and would be inconsistent\nwith the other modes (e.g., matching, explicit refspecs, pushing\nnon-branches, etc).\n\n-Peff\n"},{"id":"213814","messageId":"CALkWK0nKvTiGsjO4zF81nsSuUM=MmmbpdzHWB=4hFR2PiB+LWg@mail.gmail.com","threadId":"33218","inReplyTo":"20130410185958.GA22394@sigill.intra.peff.net","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-10T19:31:33Z","receivedAt":"2013-04-10T19:31:33Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Jeff King wrote:\n> On Wed, Apr 10, 2013 at 11:54:34AM -0700, Junio C Hamano wrote:\n>> > If branch.$name.remote is \"when I am on this branch, I want to talk to\n>> > this remote\", that rule is not be impacted by the presence of refspecs\n>> > at all.\n>>\n>> So running the above while on 'maint' will send master and next to\n>> the remote your \"git push\" would send to when run without any\n>> refspecs?\n>\n> Exactly. The remote selection is orthogonal to the refspecs provided,\n> and only cares about which branch you are on.\n>\n> Which is still kind of weird, because why should the branch you are on\n> affect the default push location? But that is how default \"matching\" has\n> always behaved, and we would remain consistent with that.\n\ngit push -- master next; pushes to my current branch's\nbranch..pushremote? Isn't that a disaster?\n\n>> That is internally consistent and understandable, and I have no\n>> objection to it. Certainly much better than basing the decision on\n>> branch.{master,next}.remote as I thought you were suggesting to do.\n>\n> No, I am not suggesting that. I can see how such a command might be\n> useful (i.e. \"push master to where it goes, next to where it goes\",\n> where \"goes\" is defined by the upstream config). But that is not\n> remotely close to how \"git push\" works now, and would be inconsistent\n> with the other modes (e.g., matching, explicit refspecs, pushing\n> non-branches, etc).\n\nOtherwise, I think we're consistent. git push master; pushes the\nrefspec master (with no explicit : counterpart) to the \"default\nplace to push to\" (either depending on which branch I am, or global).\nI think Junio was mixing up refspecs with refs (branches, and hence\nbranch configuration) earlier. git push origin; pushes to \"default\nrefspecs\" on the remote origin. By extension, git push; should push\n\"default respecs\" to the \"default place to push to\". The \"default\nrefspecs\" in this context is determined by push.default, which is the\nproblem.\n"},{"id":"213815","messageId":"CALkWK0n_qTThL+_k3tcD_R4PMddBROqZDEaRHUy=GHOO_Q1keQ@mail.gmail.com","threadId":"33218","inReplyTo":"CALkWK0nKvTiGsjO4zF81nsSuUM=MmmbpdzHWB=4hFR2PiB+LWg@mail.gmail.com","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-10T19:33:17Z","receivedAt":"2013-04-10T19:33:17Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Ramkumar Ramachandra wrote:\n> Otherwise, I think we're consistent. git push master; pushes the\n> refspec master (with no explicit : counterpart) to the \"default\n> place to push to\" (either depending on which branch I am, or global).\n> I think Junio was mixing up refspecs with refs (branches, and hence\n> branch configuration) earlier. git push origin; pushes to \"default\n> refspecs\" on the remote origin. By extension, git push; should push\n> \"default respecs\" to the \"default place to push to\". The \"default\n> refspecs\" in this context is determined by push.default, which is the\n> problem.\n\nMajor thinko here. The problem is git push master; choosing the\n\"default place to push to\" depending on what branch I'm in. A plain\ngit push; is just fine.\n"},{"id":"213819","messageId":"20130410195256.GA24177@sigill.intra.peff.net","threadId":"33218","inReplyTo":"CALkWK0nKvTiGsjO4zF81nsSuUM=MmmbpdzHWB=4hFR2PiB+LWg@mail.gmail.com","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-04-10T19:52:57Z","receivedAt":"2013-04-10T19:52:57Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Apr 11, 2013 at 01:01:33AM +0530, Ramkumar Ramachandra wrote:\n\n> Jeff King wrote:\n> > On Wed, Apr 10, 2013 at 11:54:34AM -0700, Junio C Hamano wrote:\n> >> > If branch.$name.remote is \"when I am on this branch, I want to talk to\n> >> > this remote\", that rule is not be impacted by the presence of refspecs\n> >> > at all.\n> >>\n> >> So running the above while on 'maint' will send master and next to\n> >> the remote your \"git push\" would send to when run without any\n> >> refspecs?\n> >\n> > Exactly. The remote selection is orthogonal to the refspecs provided,\n> > and only cares about which branch you are on.\n> >\n> > Which is still kind of weird, because why should the branch you are on\n> > affect the default push location? But that is how default \"matching\" has\n> > always behaved, and we would remain consistent with that.\n> \n> git push -- master next; pushes to my current branch's\n> branch..pushremote? Isn't that a disaster?\n\nMaybe. But no more so than the current:\n\n git push\n\nwhich may also push master and next to the same remote. As I said in an\nearlier message, I would be OK with allowing both or neither, but\nallowing one but not the other is even more confusing.\n\nIf we changed push.default=matching to ignore branch.*.remote, then that\nwould be consistent, and would probably be safer over all. It is a\nregression, but I doubt that anybody was using branch.*.remote for this;\nit really only makes sense with the \"upstream\" mode.\n\n-Peff\n"},{"id":"213820","messageId":"CALkWK0k44+VnrGTXESdap2nRomdYH8xwz_T2JdhYtSrPR+89sw@mail.gmail.com","threadId":"33218","inReplyTo":"CALkWK0nKvTiGsjO4zF81nsSuUM=MmmbpdzHWB=4hFR2PiB+LWg@mail.gmail.com","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-10T19:53:57Z","receivedAt":"2013-04-10T19:53:57Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Ramkumar Ramachandra wrote:\n> git push -- master next; pushes to my current branch's\n> branch..pushremote? Isn't that a disaster?\n\nActually, branch..pushremote already breaks the current design\nin a way, as Junio pointed out in a different email: a push.default\nset to anything except \"current\" is already nonsensical. Why should\n\"matching\" branches be pushed to the remote that my current branch\nspecifies? That might well have their own branch..pushremote\nconfigured, which should be respected.\n\nWe should fix this now. I think the fault lies in the rather old\ndesign of push.default. Do you have any suggestions as what would\nmake sense here? Ultimately, I think a git push; needs to pick\nremotes for each refspec separately. The orthogonal design is\ndefinitely not right in my opinion.\n\nAs the author of branch..pushremote, I apologize for not having\ncaught this earlier. I've been using push.default = current for a\nlong time, and don't often think about the other settings.\n"},{"id":"213825","messageId":"20130410200512.GB27070@google.com","threadId":"33218","inReplyTo":"CALkWK0k44+VnrGTXESdap2nRomdYH8xwz_T2JdhYtSrPR+89sw@mail.gmail.com","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-04-10T20:05:12Z","receivedAt":"2013-04-10T20:05:12Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Ramkumar Ramachandra wrote:\n> Ramkumar Ramachandra wrote:\n\n>> git push -- master next; pushes to my current branch's\n>> branch..pushremote? Isn't that a disaster?\n>\n> Actually, branch..pushremote already breaks the current design\n> in a way\n\nI don't see a big problem here, actually. What's so wrong with\nbranch..remote affecting what \"git push\" does? If\nbranch.crazy-feature.remote is my-personal-remote and I run\n\n\tgit push\n\nand \"[push] default = upstream\", then it is obvious what the user\nwanted to happen. But what about when \"[push] default = matching\"?\nWhich of the following behaviors is correct?\n\n a) Error: you didn't tell me which remote to push to.\n b) Just behave like \"git push my-personal-remote :\".\n c) Ignore which branch is the current branch and behave like\n \"git push origin :\".\n\nHow about when \"[push] default = current\"?\n\nExcept that people might have scripts or habits tied to the current\nbehavior, any of (a), (b), and (c) sounds fine to me. (b) is the\nobvious choice for historical reasons.\n\nNow if I rely on the proposed DWIM and run\n\n\tgit push master\n\nthen the corresponding choices are:\n\n a) Error: you didn't tell me which remote to push to.\n b) Just behave like \"git push my-personal-remote master\".\n c) Behave like \"git push origin master\".\n \n(b) is not a good choice there, but (a) and (c) look equally fine.\n"},{"id":"213827","messageId":"CALkWK0nAMVKuDg4wmwujkpNxAF9zxQEdsZXyUzr+w4zVpWDCzA@mail.gmail.com","threadId":"33218","inReplyTo":"20130410195256.GA24177@sigill.intra.peff.net","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-10T20:05:34Z","receivedAt":"2013-04-10T20:05:34Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Jeff King wrote:\n> Maybe. But no more so than the current:\n>\n> git push\n>\n> which may also push master and next to the same remote.\n\nI would argue that this was not really a problem in practice, until I\nintroduced branch..pushremote.\n\nLet us imagine that I was working on artagnon/git.git (remote: ram), a\nfork of git/git.git (remote: origin) earlier. My fork contains the\nlink and implicit-push branches in addition to the master, next and pu\nbranches, which are present on both. When I push from my\nimplicit-push branch with push.default = matching, I'm updating all\nthe matching refs on the remote ram (since branch.implicit-push.remote\nis set to ram), which is fine. Now, I git push while on branch\nmaster. My push is simply rejected, as I don't have write access to\nthe remote origin.\n\nThis is designed exactly for the read-only upstream, read-write fork\nscenario. If I had write access to upstream (where we're essentially\nregression to a centralized model), we'd have some major confusion.\n\n> As I said in an\n> earlier message, I would be OK with allowing both or neither, but\n> allowing one but not the other is even more confusing.\n\nWhat is the point of allowing something internally consistent, but\nnonsensical? You should complain.\n"},{"id":"213826","messageId":"20130410200548.GC24177@sigill.intra.peff.net","threadId":"33218","inReplyTo":"CALkWK0k44+VnrGTXESdap2nRomdYH8xwz_T2JdhYtSrPR+89sw@mail.gmail.com","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-04-10T20:05:48Z","receivedAt":"2013-04-10T20:05:48Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Apr 11, 2013 at 01:23:57AM +0530, Ramkumar Ramachandra wrote:\n\n> Ramkumar Ramachandra wrote:\n> > git push -- master next; pushes to my current branch's\n> > branch..pushremote? Isn't that a disaster?\n> \n> Actually, branch..pushremote already breaks the current design\n> in a way, as Junio pointed out in a different email: a push.default\n> set to anything except \"current\" is already nonsensical. Why should\n> \"matching\" branches be pushed to the remote that my current branch\n> specifies? That might well have their own branch..pushremote\n> configured, which should be respected.\n\nI'm not sure that it should be respected. \"master\" is short for\n\"refs/heads/master:refs/heads/master\", and does not mean \"push master to\nwhere I have it configured to go\" at all. That may be what the user\nmeans, but changing how \"git push\" works is going to create\ninconsistency with other cases.\n\n> We should fix this now. I think the fault lies in the rather old\n> design of push.default. Do you have any suggestions as what would\n> make sense here? Ultimately, I think a git push; needs to pick\n> remotes for each refspec separately. The orthogonal design is\n> definitely not right in my opinion.\n\nRight, the example above might include multiple remotes if pushremote is\nrespected. Or it might not come up with an answer at all for a tag.\nIf you do:\n\n git push -- v1.2.3 master\n\nwhere does v1.2.3 go? To remote.pushdefault? That seems simple and\nconsistent, as there is no ref-specific pushremote defined. But I'd\nguess that the user probably _wanted_ it to go to\nbranch.master.pushremote.\n\n> As the author of branch..pushremote, I apologize for not having\n> caught this earlier. I've been using push.default = current for a\n> long time, and don't often think about the other settings.\n\nI don't think pushremote introduced the problem. It is much older than\nthat, and dates back to respecting branch.*.remote at all for pushes,\neven though push.default=matching (and before we had push.default, it\nwas always matching) does not have anything to do with the current\nbranch.\n\n-Peff\n"},{"id":"213829","messageId":"20130410201103.GD24177@sigill.intra.peff.net","threadId":"33218","inReplyTo":"20130410200512.GB27070@google.com","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-04-10T20:11:03Z","receivedAt":"2013-04-10T20:11:03Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Apr 10, 2013 at 01:05:12PM -0700, Jonathan Nieder wrote:\n\n> I don't see a big problem here, actually. What's so wrong with\n> branch..remote affecting what \"git push\" does? If\n> branch.crazy-feature.remote is my-personal-remote and I run\n> \n> \tgit push\n> \n> and \"[push] default = upstream\", then it is obvious what the user\n> wanted to happen. But what about when \"[push] default = matching\"?\n> Which of the following behaviors is correct?\n> \n> a) Error: you didn't tell me which remote to push to.\n> b) Just behave like \"git push my-personal-remote :\".\n> c) Ignore which branch is the current branch and behave like\n> \"git push origin :\".\n> \n> How about when \"[push] default = current\"?\n> \n> Except that people might have scripts or habits tied to the current\n> behavior, any of (a), (b), and (c) sounds fine to me. (b) is the\n> obvious choice for historical reasons.\n\nI think (b) could be quite surprising to a user. I suspect it hasn't\ncome up because people just don't work with a lot of different remotes\nin practice.\n\n> Now if I rely on the proposed DWIM and run\n> \n> \tgit push master\n> \n> then the corresponding choices are:\n> \n> a) Error: you didn't tell me which remote to push to.\n> b) Just behave like \"git push my-personal-remote master\".\n> c) Behave like \"git push origin master\".\n> \n> (b) is not a good choice there, but (a) and (c) look equally fine.\n\nMy complaint with anything but (b) is that you can't use a relatively\nsimple rule (\"if you do not specify a remote, we fallback to defaults,\nin this order\"). Now the rule is different depending on what is in the\nrefspecs. If I say \"git push HEAD\", where should it go? Does it respect\nbranch.*.remote or not?\n\n-Peff\n"},{"id":"213832","messageId":"CALkWK0mEe+p3RX2tamW8dmdY_eP74Rdh_pZDRDPNfzX0TOKQCQ@mail.gmail.com","threadId":"33218","inReplyTo":"20130410200548.GC24177@sigill.intra.peff.net","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-10T20:19:54Z","receivedAt":"2013-04-10T20:19:54Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Jeff King wrote:\n> On Thu, Apr 11, 2013 at 01:23:57AM +0530, Ramkumar Ramachandra wrote:\n>\n>> Ramkumar Ramachandra wrote:\n>> > git push -- master next; pushes to my current branch's\n>> > branch..pushremote? Isn't that a disaster?\n>>\n>> Actually, branch..pushremote already breaks the current design\n>> in a way, as Junio pointed out in a different email: a push.default\n>> set to anything except \"current\" is already nonsensical. Why should\n>> \"matching\" branches be pushed to the remote that my current branch\n>> specifies? That might well have their own branch..pushremote\n>> configured, which should be respected.\n>\n> I'm not sure that it should be respected. \"master\" is short for\n> \"refs/heads/master:refs/heads/master\", and does not mean \"push master to\n> where I have it configured to go\" at all. That may be what the user\n> means, but changing how \"git push\" works is going to create\n> inconsistency with other cases.\n\nYes, I know \"master\" refers to the refspec in the above, not the ref\n(ie. branch). Hence branch configuration should have nothing to do\nwith this. That's just the way things currently are: doesn't mean\nthat it's perfect; and I'm just throwing ideas around.\n\n>> We should fix this now. I think the fault lies in the rather old\n>> design of push.default. Do you have any suggestions as what would\n>> make sense here? Ultimately, I think a git push; needs to pick\n>> remotes for each refspec separately. The orthogonal design is\n>> definitely not right in my opinion.\n>\n> Right, the example above might include multiple remotes if pushremote is\n> respected. Or it might not come up with an answer at all for a tag.\n> If you do:\n>\n> git push -- v1.2.3 master\n>\n> where does v1.2.3 go? To remote.pushdefault? That seems simple and\n> consistent, as there is no ref-specific pushremote defined.\n\nremote.pushdefault indeed.\n\n> But I'd\n> guess that the user probably _wanted_ it to go to\n> branch.master.pushremote.\n\nHuh, why? Simply because he specified master alongside it? How can\nwe infer what you said in a consistent system?\n"},{"id":"213833","messageId":"20130410202105.GE24177@sigill.intra.peff.net","threadId":"33218","inReplyTo":"CALkWK0nAMVKuDg4wmwujkpNxAF9zxQEdsZXyUzr+w4zVpWDCzA@mail.gmail.com","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-04-10T20:21:05Z","receivedAt":"2013-04-10T20:21:05Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Apr 11, 2013 at 01:35:34AM +0530, Ramkumar Ramachandra wrote:\n\n> Jeff King wrote:\n> > Maybe. But no more so than the current:\n> >\n> > git push\n> >\n> > which may also push master and next to the same remote.\n> \n> I would argue that this was not really a problem in practice, until I\n> introduced branch..pushremote.\n> \n> Let us imagine that I was working on artagnon/git.git (remote: ram), a\n> fork of git/git.git (remote: origin) earlier. My fork contains the\n> link and implicit-push branches in addition to the master, next and pu\n> branches, which are present on both. When I push from my\n> implicit-push branch with push.default = matching, I'm updating all\n> the matching refs on the remote ram (since branch.implicit-push.remote\n> is set to ram), which is fine. Now, I git push while on branch\n> master. My push is simply rejected, as I don't have write access to\n> the remote origin.\n> \n> This is designed exactly for the read-only upstream, read-write fork\n> scenario. If I had write access to upstream (where we're essentially\n> regression to a centralized model), we'd have some major confusion.\n\nI don't see how pushremote changes that. It was already a problem with\nbranch.*.remote, no?\n\nI have a similar remote setup in my git.git repository. But all of my\nbranch.*.remote variables point to origin, because my branches are based\noff of Junio's master. A matching push goes to the wrong place (and I\nhave screwed it up many times; it is nice that I do not have write\naccess to Junio's repository). The is broken without having pushremote\nat all (and the proper fix is your remote.pushdefault).\n\n> > As I said in an\n> > earlier message, I would be OK with allowing both or neither, but\n> > allowing one but not the other is even more confusing.\n> \n> What is the point of allowing something internally consistent, but\n> nonsensical? You should complain.\n\nIf I were designing it today, I definitely think complaining is the\nright thing to do. My only hesitation is the backwards compatibility.\n\nIf we are not going to break the existing behavior, I think it can be\nargued that consistency and simplicity of the rules is important, so the\nuser can predict what will happen. But the more we discuss, the more I\nthink we should simply change the current behavior (to stop respecting\nbranch.* config with \"matching\"), which just seems wrong to me. Then we\ncan be simple and consistent, and do what the user probably intended.\n\n-Peff\n"},{"id":"213834","messageId":"7vli8qkuh3.fsf@alter.siamese.dyndns.org","threadId":"33218","inReplyTo":"20130410195256.GA24177@sigill.intra.peff.net","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-10T20:21:12Z","receivedAt":"2013-04-10T20:21:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> If we changed push.default=matching to ignore branch.*.remote, then that\n> would be consistent, and would probably be safer over all. It is a\n> regression, but I doubt that anybody was using branch.*.remote for this;\n> it really only makes sense with the \"upstream\" mode.\n\nTrue.\n"},{"id":"213835","messageId":"20130410202456.GF24177@sigill.intra.peff.net","threadId":"33218","inReplyTo":"CALkWK0mEe+p3RX2tamW8dmdY_eP74Rdh_pZDRDPNfzX0TOKQCQ@mail.gmail.com","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-04-10T20:24:56Z","receivedAt":"2013-04-10T20:24:56Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Apr 11, 2013 at 01:49:54AM +0530, Ramkumar Ramachandra wrote:\n\n> > Right, the example above might include multiple remotes if pushremote is\n> > respected. Or it might not come up with an answer at all for a tag.\n> > If you do:\n> >\n> > git push -- v1.2.3 master\n> >\n> > where does v1.2.3 go? To remote.pushdefault? That seems simple and\n> > consistent, as there is no ref-specific pushremote defined.\n> \n> remote.pushdefault indeed.\n> \n> > But I'd\n> > guess that the user probably _wanted_ it to go to\n> > branch.master.pushremote.\n> \n> Huh, why? Simply because he specified master alongside it? How can\n> we infer what you said in a consistent system?\n\nThat's kind of my point. Why would they put two refs together in a\nsingle push command? Did they mean \"I am pushing up master, and since I\njust tagged it, send the tag along, too\"? Or did they really mean to\npush them to two different places? If so, why not just run two separate\npush commands?\n\nI am not saying git should guess that the user wanted the tag to along\nwith master. I am saying that the set of rules to come to that\nconclusion is going to be too baroque for the user to understand, and\ntoo often wrong in other cases, and that we should not go there.\n\n-Peff\n"},{"id":"213836","messageId":"7vhajeku7a.fsf@alter.siamese.dyndns.org","threadId":"33218","inReplyTo":"CALkWK0k44+VnrGTXESdap2nRomdYH8xwz_T2JdhYtSrPR+89sw@mail.gmail.com","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-10T20:27:05Z","receivedAt":"2013-04-10T20:27:05Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra writes:\n\n> As the author of branch..pushremote, I apologize for not having\n> caught this earlier. I've been using push.default = current for a\n> long time, and don't often think about the other settings.\n\nPossibly, but I do not know it is such a big issue.\n\nOn the other hand, a good thing is that the remote.pushdefault makes\nperfect sense whether you use the upstream mode or the matching\nmode. I vaguely recall that I kept telling you that the overall\ndefault should be there and per-branch stuff can come later if/as\nneeded, to which you resisted for a couple of rounds of reviews and\nI couldn't quite figure out where the resistance was coming from.\nCome to think of it, perhaps that might be rooted in the same\nreason of not thinking about users of \"matching\" mode. I dunno, and\nI do not think it matters.\n"},{"id":"213838","messageId":"CALkWK0nfJezWbd3+VfA+DMqUNbekSJJJ539AmhQT37kkap_qeg@mail.gmail.com","threadId":"33218","inReplyTo":"20130410202105.GE24177@sigill.intra.peff.net","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-10T20:41:01Z","receivedAt":"2013-04-10T20:41:01Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Jeff King wrote:\n> On Thu, Apr 11, 2013 at 01:35:34AM +0530, Ramkumar Ramachandra wrote:\n>\n>> Jeff King wrote:\n>> > Maybe. But no more so than the current:\n>> >\n>> > git push\n>> >\n>> > which may also push master and next to the same remote.\n>>\n>> I would argue that this was not really a problem in practice, until I\n>> introduced branch..pushremote.\n>>\n>> Let us imagine that I was working on artagnon/git.git (remote: ram), a\n>> fork of git/git.git (remote: origin) earlier. My fork contains the\n>> link and implicit-push branches in addition to the master, next and pu\n>> branches, which are present on both. When I push from my\n>> implicit-push branch with push.default = matching, I'm updating all\n>> the matching refs on the remote ram (since branch.implicit-push.remote\n>> is set to ram), which is fine. Now, I git push while on branch\n>> master. My push is simply rejected, as I don't have write access to\n>> the remote origin.\n>>\n>> This is designed exactly for the read-only upstream, read-write fork\n>> scenario. If I had write access to upstream (where we're essentially\n>> regression to a centralized model), we'd have some major confusion.\n>\n> I don't see how pushremote changes that. It was already a problem with\n> branch.*.remote, no?\n\nTechnically, it changes nothing. pushremote is only an enabler for\nmore complex scenarios where git push; breaking user expectations is\nmagnified.\n\nAccording to me, what branch..pushremote suddenly starts\nsupporting (apart from the use I intended for it) is each branch\nhaving different read/ write access. So, we're back to git.git where\nJunio has graciously given me write support to pu, but not next or\nmaster. So I set up branch.master.pushremote and\nbranch.next.pushremote to ram and run git push; from pu. Disaster:\nthe pu ref went through fine, but master and next failed to get pushed\ndespite me specifying a proper pushremote for them.\n\n> I have a similar remote setup in my git.git repository. But all of my\n> branch.*.remote variables point to origin, because my branches are based\n> off of Junio's master. A matching push goes to the wrong place (and I\n> have screwed it up many times; it is nice that I do not have write\n> access to Junio's repository). The is broken without having pushremote\n> at all (and the proper fix is your remote.pushdefault).\n\nYeah, I can't believe I lived without remote.pushdefault for this long.\n\n> If we are not going to break the existing behavior, I think it can be\n> argued that consistency and simplicity of the rules is important, so the\n> user can predict what will happen. But the more we discuss, the more I\n> think we should simply change the current behavior (to stop respecting\n> branch.* config with \"matching\"), which just seems wrong to me. Then we\n> can be simple and consistent, and do what the user probably intended.\n\nSo there are some push.default options that respect branch.* config\n(ie. \"current\"), and others that don't (ie. \"matching\"). I would\nargue that push.default is badly designed to begin with, so the\nsolution makes sense to me even if the patch is a bit of hack; we\nnever guaranteed that the various push.default options respect the\nsame configuration variables.\n"},{"id":"213841","messageId":"CALkWK0k_gYWg9=zjRKGrq-evsWG+hCrLjrpLfYp=_uoHVKBzHw@mail.gmail.com","threadId":"33218","inReplyTo":"20130410202456.GF24177@sigill.intra.peff.net","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-10T20:55:59Z","receivedAt":"2013-04-10T20:55:59Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Jeff King wrote:\n> On Thu, Apr 11, 2013 at 01:49:54AM +0530, Ramkumar Ramachandra wrote:\n>> Huh, why? Simply because he specified master alongside it? How can\n>> we infer what you said in a consistent system?\n>\n> That's kind of my point. Why would they put two refs together in a\n> single push command? Did they mean \"I am pushing up master, and since I\n> just tagged it, send the tag along, too\"? Or did they really mean to\n> push them to two different places? If so, why not just run two separate\n> push commands?\n\nI disagree. The protocol was built ground up to support updating\nmultiple refs in the same git push. Running N separate push commands\nis _not_ the same thing at all; it running N times as slowly aside.\n\nPushing multiple refs is a valid and cogent usecase (while multiple\nremotes is not). git is a distributed system: I make lots of changes\nto various branches, tags and decide to push only when I'm taking a\nbreak for lunch: at this point, I want to update all my refs on the\nremote. In other words, I batch up ref updates because git is _meant_\nto do that: creating/ modifying/ moving/ deleting refs is super-fast\n(and happens all the time), while pushing is a slow and dangerous\n(because gc runs) operation.\n"},{"id":"213842","messageId":"CALkWK0=UacRnjWJJCtJttk4W_8cbTXQbpQTDJ2+45S9CxXXzAw@mail.gmail.com","threadId":"33218","inReplyTo":"CALkWK0nfJezWbd3+VfA+DMqUNbekSJJJ539AmhQT37kkap_qeg@mail.gmail.com","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-10T21:02:20Z","receivedAt":"2013-04-10T21:02:20Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Ramkumar Ramachandra wrote:\n> Jeff King wrote:\n>> If we are not going to break the existing behavior, I think it can be\n>> argued that consistency and simplicity of the rules is important, so the\n>> user can predict what will happen. But the more we discuss, the more I\n>> think we should simply change the current behavior (to stop respecting\n>> branch.* config with \"matching\"), which just seems wrong to me. Then we\n>> can be simple and consistent, and do what the user probably intended.\n>\n> So there are some push.default options that respect branch.* config\n> (ie. \"current\"), and others that don't (ie. \"matching\"). I would\n> argue that push.default is badly designed to begin with, so the\n> solution makes sense to me even if the patch is a bit of hack; we\n> never guaranteed that the various push.default options respect the\n> same configuration variables.\n\nIf we're going to break \"matching\" anyway, let's break it fully. I\npropose that we make it respect each individual branch's\nbranch..pushremote/ branch..remote and push the branch to\nthat remote. That'll let us design a git push -- master\nimplicit-push; that actually makes sense.\n"},{"id":"213843","messageId":"20130410210455.GA2999@sigill.intra.peff.net","threadId":"33218","inReplyTo":"CALkWK0k_gYWg9=zjRKGrq-evsWG+hCrLjrpLfYp=_uoHVKBzHw@mail.gmail.com","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-04-10T21:04:55Z","receivedAt":"2013-04-10T21:04:55Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Apr 11, 2013 at 02:25:59AM +0530, Ramkumar Ramachandra wrote:\n\n> Jeff King wrote:\n> > On Thu, Apr 11, 2013 at 01:49:54AM +0530, Ramkumar Ramachandra wrote:\n> >> Huh, why? Simply because he specified master alongside it? How can\n> >> we infer what you said in a consistent system?\n> >\n> > That's kind of my point. Why would they put two refs together in a\n> > single push command? Did they mean \"I am pushing up master, and since I\n> > just tagged it, send the tag along, too\"? Or did they really mean to\n> > push them to two different places? If so, why not just run two separate\n> > push commands?\n> \n> I disagree. The protocol was built ground up to support updating\n> multiple refs in the same git push. Running N separate push commands\n> is _not_ the same thing at all; it running N times as slowly aside.\n\nBut I think all of this discussion just reinforces my point. We do not\nhave to agree on what the user intended. But the fact that we do not\nagree means that out of a sample size of 2 users, we have 2 different\nthings the user expects to happen. If we choose a behavior and say \"this\nmakes sense\", then the other half of the users are going to be confused\nor annoyed.\n\n-Peff\n"},{"id":"213845","messageId":"CALkWK0k-YJwT__8Tc4B4WXq30ij3i8_d6qwyOCP5RLsKF9eazQ@mail.gmail.com","threadId":"33218","inReplyTo":"20130410210455.GA2999@sigill.intra.peff.net","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-10T21:11:13Z","receivedAt":"2013-04-10T21:11:13Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Jeff King wrote:\n> But I think all of this discussion just reinforces my point. We do not\n> have to agree on what the user intended. But the fact that we do not\n> agree means that out of a sample size of 2 users, we have 2 different\n> things the user expects to happen. If we choose a behavior and say \"this\n> makes sense\", then the other half of the users are going to be confused\n> or annoyed.\n\nYes, disagreement is healthy. My point is that we should have \"sane\"\ndefaults, and fine-grained configurability so that uses who disagree\ncan maintain their own configs. In this case, respecting a\nbranch.*.remote for each branch is more fine-grained, while not doing\nso is coarse and makes me unhappy. Then again, we don't have to go\noverboard and design another ten configuration variables, but we can\natleast improve on what we already have without breaking consistency\n(but we have to minimally break backward compatibility).\n"},{"id":"213849","messageId":"CALkWK0m9karG=geF4KYapWJfit7zisiZ46cXNNzjh3+3yUpgVw@mail.gmail.com","threadId":"33218","inReplyTo":"7vhajeku7a.fsf@alter.siamese.dyndns.org","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-10T21:15:50Z","receivedAt":"2013-04-10T21:15:50Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n> On the other hand, a good thing is that the remote.pushdefault makes\n> perfect sense whether you use the upstream mode or the matching\n> mode. I vaguely recall that I kept telling you that the overall\n> default should be there and per-branch stuff can come later if/as\n> needed, to which you resisted for a couple of rounds of reviews and\n> I couldn't quite figure out where the resistance was coming from.\n> Come to think of it, perhaps that might be rooted in the same\n> reason of not thinking about users of \"matching\" mode. I dunno, and\n> I do not think it matters.\n\nremote.pushdefault is simple; it doesn't open up interesting\npossibilities like branch..pushremote does (I mentioned\nbranch-specific r/w access somewhere else in the thread). Because of\nmy obsession with \"current\", I never think of the repository as a\nwhole but each branch separately tracking a remote.\n"},{"id":"213850","messageId":"20130410211824.GC27070@google.com","threadId":"33218","inReplyTo":"CALkWK0k-YJwT__8Tc4B4WXq30ij3i8_d6qwyOCP5RLsKF9eazQ@mail.gmail.com","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-04-10T21:18:24Z","receivedAt":"2013-04-10T21:18:24Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Ramkumar Ramachandra wrote:\n\n> My point is that we should have \"sane\"\n> defaults, and fine-grained configurability so that uses who disagree\n> can maintain their own configs.\n\nI don't agree with this principle. I like a tool that behaves sanely\nwith little work and that is flexible enough to do hard things when\nthat's needed. Neither of those attributes implies configurability,\nexcept in those unfortunate cases where \"behaving sanely with little\nwork on the user's part\" has to involve a different behavior from\nperson to person.\n\nWhen people disagree about sane defaults, that's a sign that we didn't\nunderstand the problem well. Often more thinking can lead to a\nsimpler answer.\n"},{"id":"213853","messageId":"CALkWK0nxpoLL4zoinE4j8y8NLHo0-b=PcimNLykCjMjOpWYEfQ@mail.gmail.com","threadId":"33218","inReplyTo":"20130410211824.GC27070@google.com","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-10T21:23:04Z","receivedAt":"2013-04-10T21:23:04Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Jonathan Nieder wrote:\n> When people disagree about sane defaults, that's a sign that we didn't\n> understand the problem well. Often more thinking can lead to a\n> simpler answer.\n\nOkay, let's see if we can all agree.\n\nIn a different email, you wrote:\n> git push master\n> ...\n> a) Error: you didn't tell me which remote to push to.\n> b) Just behave like \"git push my-personal-remote master\".\n> c) Behave like \"git push origin master\".\n\nHere, I'd argue for (d): push to branch.master.pushremote/\nbranch.master.remote/ remote.pushdefault/ origin. If others agree on\nthis, we can break \"matching\" appropriately, like I proposed earlier,\nto make everything consistent once again.\n"},{"id":"213852","messageId":"20130410212329.GD27070@google.com","threadId":"33218","inReplyTo":"20130410201103.GD24177@sigill.intra.peff.net","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-04-10T21:23:29Z","receivedAt":"2013-04-10T21:23:29Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Jeff King wrote:\n> On Wed, Apr 10, 2013 at 01:05:12PM -0700, Jonathan Nieder wrote:\n\n>> \tgit push\n>>\n>> and \"[push] default = upstream\", then it is obvious what the user\n>> wanted to happen. But what about when \"[push] default = matching\"?\n>> Which of the following behaviors is correct?\n>>\n>> a) Error: you didn't tell me which remote to push to.\n>> b) Just behave like \"git push my-personal-remote :\".\n>> c) Ignore which branch is the current branch and behave like\n>> \"git push origin :\".\n>>\n>> How about when \"[push] default = current\"?\n>>\n>> Except that people might have scripts or habits tied to the current\n>> behavior, any of (a), (b), and (c) sounds fine to me. (b) is the\n>> obvious choice for historical reasons.\n>\n> I think (b) could be quite surprising to a user. I suspect it hasn't\n> come up because people just don't work with a lot of different remotes\n> in practice.\n\nYeah, I think you're right.\n\nI'll try writing a series to switch to (c) for [push] default = matching\nand (a) for default = simple (and one of the two for default = current.\nNot sure which yet).\n\nThanks,\nJonathan\n"},{"id":"213856","messageId":"20130410212911.GE27070@google.com","threadId":"33218","inReplyTo":"CALkWK0nxpoLL4zoinE4j8y8NLHo0-b=PcimNLykCjMjOpWYEfQ@mail.gmail.com","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-04-10T21:29:11Z","receivedAt":"2013-04-10T21:29:11Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Ramkumar Ramachandra wrote:\n> Jonathan Nieder wrote:\n\n>> git push master\n>> ...\n>> a) Error: you didn't tell me which remote to push to.\n>> b) Just behave like \"git push my-personal-remote master\".\n>> c) Behave like \"git push origin master\".\n>\n> Here, I'd argue for (d): push to branch.master.pushremote/\n> branch.master.remote/ remote.pushdefault/ origin.\n\nMy first hunch is not to like this, since it means\n\n\tgit push -- master next\n\nmight push to two different remotes and because it's not obvious\nto me when it would be useful.\n\nSo I am still leaning toward the behavior Jeff suggested. That said,\nwe're probably at the point where enough scenarios have been described\nfor someone to write a patch with a clear explanation about how their\nproposed behavior takes care of them all.\n\nThanks,\nJonathan\n"},{"id":"213858","messageId":"CALkWK0kkzc04uFqLb1gsrUDJ1Thw_LGzNkPq6oz_d3+xXs8cHA@mail.gmail.com","threadId":"33218","inReplyTo":"CALkWK0=UacRnjWJJCtJttk4W_8cbTXQbpQTDJ2+45S9CxXXzAw@mail.gmail.com","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-10T21:32:08Z","receivedAt":"2013-04-10T21:32:08Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Ramkumar Ramachandra wrote:\n> If we're going to break \"matching\" anyway, let's break it fully.\n\nWait, let's not break anything. Instead, let us invent a new\npush.default that does this ref-to-remote matching, and make git push\n-- master push-implicit; consistent with that. Then \"matching\" can be\ndeprecated as usual.\n"},{"id":"213860","messageId":"CALkWK0m=iDw+N0zcfEEt1jzFD4wOOzLgyBWNyc=HZ+xLe5SBLw@mail.gmail.com","threadId":"33218","inReplyTo":"20130410212911.GE27070@google.com","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-10T21:42:20Z","receivedAt":"2013-04-10T21:42:20Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Jonathan Nieder wrote:\n> My first hunch is not to like this, since it means\n>\n> git push -- master next\n>\n> might push to two different remotes and because it's not obvious\n> to me when it would be useful.\n\nYes, it will push to two different remotes. And why is it not useful?\n If we also had something corresponding to branch..merge for\npush*, I would argue that this and branch..pushremote together\ndefine how a branch should be pushed, independent of everything else.\nLike I said earlier, I don't think of a git repository as a whole, but\nrather a collection of upstream and forked branches. Every branch is\nalways fetched from its upstream (might or might not be the same as\nfork) using branch..remote, and pushed to its fork using\nbranch..pushremote. A git push; can use the context of the\ncurrent branch to select branches (along with their configurations) to\npush, nothing more. It should not apply the configuration of the\ncurrent branch to the other branches that it's pushing; that's just\nwrong.\n\n* Can we write this branch..pushmap, effectively overriding\nbranch..merge when in push.default = upstream and simple?\n"},{"id":"213864","messageId":"20130410215658.GC6215@sigill.intra.peff.net","threadId":"33218","inReplyTo":"CALkWK0m=iDw+N0zcfEEt1jzFD4wOOzLgyBWNyc=HZ+xLe5SBLw@mail.gmail.com","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-04-10T21:56:58Z","receivedAt":"2013-04-10T21:56:58Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Apr 11, 2013 at 03:12:20AM +0530, Ramkumar Ramachandra wrote:\n\n> Jonathan Nieder wrote:\n> > My first hunch is not to like this, since it means\n> >\n> > git push -- master next\n> >\n> > might push to two different remotes and because it's not obvious\n> > to me when it would be useful.\n> \n> Yes, it will push to two different remotes. And why is it not useful?\n\nIt's not that it's not potentially useful. It's that it may be\nsurprising and annoying to users who did not want that.\n\n-Peff\n"},{"id":"213865","messageId":"CALkWK0=xzXu4_sh+7k0u-bb-=GNVSR9hq58QJsHiBZKRzfgh_w@mail.gmail.com","threadId":"33218","inReplyTo":"20130410215658.GC6215@sigill.intra.peff.net","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-10T22:06:10Z","receivedAt":"2013-04-10T22:06:10Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Jeff King wrote:\n> It's not that it's not potentially useful. It's that it may be\n> surprising and annoying to users who did not want that.\n\n... but this is a new syntax, and doesn't break any existing\nexpectations. Why are you imagining what users will expect with a git\npush -- master next; that hasn't been invented yet? From \"matching\"?\n But we've made it very clear that it's going to change soon. Users\ncan still use the git push origin master next; form as usual. In my\nopinion, this new syntax is incredibly useful if users set pushremote\nproperly.\n"},{"id":"213867","messageId":"CALkWK0=Y-pO3+g21PLCWOxx+M-7fSmp2FedMBtZ68PWU_TOHDw@mail.gmail.com","threadId":"33218","inReplyTo":"20130410215658.GC6215@sigill.intra.peff.net","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-10T22:11:33Z","receivedAt":"2013-04-10T22:11:33Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Jeff King wrote:\n> It's not that it's not potentially useful. It's that it may be\n> surprising and annoying to users who did not want that.\n\nBesides, I'm not able to imagine one scenario where this is the wrong\nor annoying thing to do. Can you provide an example?\n"},{"id":"213868","messageId":"20130410221647.GB6930@sigill.intra.peff.net","threadId":"33218","inReplyTo":"CALkWK0=xzXu4_sh+7k0u-bb-=GNVSR9hq58QJsHiBZKRzfgh_w@mail.gmail.com","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-04-10T22:16:47Z","receivedAt":"2013-04-10T22:16:47Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Apr 11, 2013 at 03:36:10AM +0530, Ramkumar Ramachandra wrote:\n\n> Jeff King wrote:\n> > It's not that it's not potentially useful. It's that it may be\n> > surprising and annoying to users who did not want that.\n> \n> ... but this is a new syntax, and doesn't break any existing\n> expectations. Why are you imagining what users will expect with a git\n> push -- master next; that hasn't been invented yet?\n\nDidn't I already say that I expected a different behavior than you are\nproposing from \"git push -- v1.2.3 master\"? \n\nYes, it is possible to lay out all of the rules in the manpage so that\nthe user can predict what will happen. But users do not always know or\nremember all of those rules, especially if it \"just works\" most of the\ntime (e.g., they usually push two branches, but this time push a tag).\nIf a command is easy to screw up, people will screw it up, and get\nsurprised and annoyed when it happens. We can say \"well, you should have\nread the manpage\", but it is much nicer if we can come up with a command\nthat is harder to screw up.\n\n-Peff\n"},{"id":"213869","messageId":"20130410222334.GC6930@sigill.intra.peff.net","threadId":"33218","inReplyTo":"CALkWK0=Y-pO3+g21PLCWOxx+M-7fSmp2FedMBtZ68PWU_TOHDw@mail.gmail.com","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-04-10T22:23:34Z","receivedAt":"2013-04-10T22:23:34Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Apr 11, 2013 at 03:41:33AM +0530, Ramkumar Ramachandra wrote:\n\n> Jeff King wrote:\n> > It's not that it's not potentially useful. It's that it may be\n> > surprising and annoying to users who did not want that.\n> \n> Besides, I'm not able to imagine one scenario where this is the wrong\n> or annoying thing to do. Can you provide an example?\n\nTo flesh out my earlier example:\n\n $ git clone https://github.com/upstream/project.git\n $ cd project\n $ hack hack hack; commit commit commit\n $ git tag -m 'something of note' my-tag\n $ git remote add me https://github.com/me/project.git\n $ git config branch.master.remote me\n $ git tag -m 'something of note'\n $ git push master my-tag\n\nMy intent there is publish both master and mytag, but my-tag goes to\norigin. It's obvious if you think carefully about (and know) the rules,\nand it's user error. But what fault do we take for designing a feature\nthat causes confusion?\n\nMaybe I am the only one who might make that mistake, and it is a\nnon-issue. But I would be much happier if git said \"hey, are you sure\nyou wanted to push to two different remotes?\". At least by default.\n\n-Peff\n"},{"id":"213871","messageId":"CALkWK0mB9BChMJpMfU8xETGG1mMJc7GjqKy1N5RWgBeyKu+HwA@mail.gmail.com","threadId":"33218","inReplyTo":"20130410222334.GC6930@sigill.intra.peff.net","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-10T22:31:23Z","receivedAt":"2013-04-10T22:31:23Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Jeff King wrote:\n> To flesh out my earlier example:\n>\n> $ git clone https://github.com/upstream/project.git\n> $ cd project\n> $ hack hack hack; commit commit commit\n> $ git tag -m 'something of note' my-tag\n> $ git remote add me https://github.com/me/project.git\n> $ git config branch.master.remote me\n> $ git tag -m 'something of note'\n> $ git push master my-tag\n>\n> My intent there is publish both master and mytag, but my-tag goes to\n> origin. It's obvious if you think carefully about (and know) the rules,\n> and it's user error. But what fault do we take for designing a feature\n> that causes confusion?\n\nGood example. Sorry, I misunderstood your one-liner. I agree that\nthis is confusing. Tags are a bit of an outlier, and we have to think\nof some way to behave sensibly with them. I'll let you know if I\nthink of something in the next few hours.\n"},{"id":"213909","messageId":"CALkWK0nvTisYCFjxwuGaBbWawwBahzeBHZ84rFkUYL8sjJuxvw@mail.gmail.com","threadId":"33218","inReplyTo":"20130410222334.GC6930@sigill.intra.peff.net","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-11T07:38:48Z","receivedAt":"2013-04-11T07:38:48Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Jeff King wrote:\n> $ git clone https://github.com/upstream/project.git\n> $ cd project\n> $ hack hack hack; commit commit commit\n> $ git tag -m 'something of note' my-tag\n> $ git remote add me https://github.com/me/project.git\n> $ git config branch.master.remote me\n> $ git tag -m 'something of note'\n> $ git push master my-tag\n\nTags have nothing to do with branches, and it is illogical to respect\nbranch.* when pushing a tag. You've illustrated a common case when\nthe user creates a tag on a specific branch and immediately pushes it.\n I would argue that optimizing our tools for this specific usecase\nbreaks the general case. What if I create a branch on master, and\ndecide to push the tag after checking out implicit-push and doing some\nwork on it? Does that not break user expectations?\n\nIn the \"I push to the same place I pull from\" (aka. single-remote)\ncase, there are never any problems and even \"matching\" works fine.\nHowever, in the triangular workflow (aka. multiple-remote) case, you\nmust give git enough information about your workflow for it to DTRT.\nI will argue that, in the above example, you have not configured git\nfor a multiple-remote case, and that you cannot expect it to DTRT\nsince you have supplied insufficient information. As to how to\nconfigure git for the general multiple-remote case:\n\nLet us imagine that origin points to git/git.git (upstream), ram\npoints to artagnon/git.git and peff points to peff/git.git. I fork\noff from upstream and have various local branches that only have\ncorresponding refs in ram (say implicit-push). Then, you fork off\nfrom me, and have various local branches that only have corresponding\nrefs in peff (say implicit-push-next). I have peff as a configured\nremote, because I routinely review the changes you make to my fork.\nIn this case, I must have:\n\n- push.default set to anything but matching, because matching makes no\nsense in the multiple-remote scenario*.\n\n- remote.default set to origin, because this is where I get new code\nfrom for all branches.\n\n- remote.pushdefault set to ram, because this is where I publish all\nmy refs to (whether branches or tags). I might have local branches\nthat I will never publish, but that's a separate issue. The point is\nthat all my tags will always be published here.\n\n- branch.implicit-push.remote set to ram, because this is the correct\nupstream for the implicit-push branch.\n\n- branch.implicit-push-next.remote set to peff, because this is the\ncorrect upstream for the implicit-push-next branch.\n\n- branch.implicit-push-next.pushremote set to null**, because I will\nnever want to push this branch.\n\n(Note that branch.implicit-push.pushremote is unnecessary because\nremote.pushdefault takes care of that)\n\nWith these settings, git push will always DTRT when you specify\nnothing, just a remote, or just a refspec. Ofcourse, you can specify\nboth and be explicit (which is what we do now). Does this make sense?\n Should we document this in gitworkflows.txt so that users know what\nis expected of them when they move from a single-remote setup to a\nmulti-remote setup?\n\n* I will definitely push for the deprecation of push.default=matching,\nbut I doubt we need to invent a new push.default. current makes a lot\nof sense to me personally.\n\n** Yet to be invented.\n"},{"id":"213911","messageId":"CALkWK0k+rsh-Ft3=+Fz2DkV5btdLg-bCJzJCKxgxMyNcmpj++w@mail.gmail.com","threadId":"33218","inReplyTo":"CALkWK0nvTisYCFjxwuGaBbWawwBahzeBHZ84rFkUYL8sjJuxvw@mail.gmail.com","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-11T07:45:28Z","receivedAt":"2013-04-11T07:45:28Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Ramkumar Ramachandra wrote:\n> - branch.implicit-push-next.pushremote set to null**, because I will\n> never want to push this branch.\n\nCurrently, I have a hacky workaround: I set\nbranch.implicit-push-next.pushremote to a remote that I don't have\nwrite access to (ie. origin), effectively failing all my attempts to\npush this branch.\n"},{"id":"214011","messageId":"7vppy0hhk7.fsf@alter.siamese.dyndns.org","threadId":"33218","inReplyTo":"CALkWK0nvTisYCFjxwuGaBbWawwBahzeBHZ84rFkUYL8sjJuxvw@mail.gmail.com","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-11T21:40:40Z","receivedAt":"2013-04-11T21:40:40Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra writes:\n\n> Let us imagine that origin points to git/git.git (upstream), ram\n> points to artagnon/git.git and peff points to peff/git.git. I fork\n> off from upstream and have various local branches that only have\n> corresponding refs in ram (say implicit-push). Then, you fork off\n> from me, and have various local branches that only have corresponding\n> refs in peff (say implicit-push-next). I have peff as a configured\n> remote, because I routinely review the changes you make to my fork.\n> In this case, I must have:\n>\n> - push.default set to anything but matching, because matching makes no\n> sense in the multiple-remote scenario*.\n\nThe \"matching\" style makes sense only when pushing to your default\npublishing repository, _and_ your work style is to finish working on\nall branches that matter before pushing things out. Instead of\nkeeping a configuration file on your local end that says \"here are\nthe branches I want to publish\", you let the remote side remember\nthem for you.\n\nWhen pushing into other kinds of repositories (e.g. you can update\nsome but not all of the branches, or you want to touch only some of\nthem and not others even if you have enough privilege to update any\nof them) or when you do not \"batch\" and push out one branch as work\non it is done, while other branches that you would eventually\npublish are still not ready, \"matching\" is not for you.\n\n> - remote.default set to origin, because this is where I get new code\n> from for all branches.\n\nOK.\n\n> - remote.pushdefault set to ram, because this is where I publish all\n> my refs to (whether branches or tags). I might have local branches\n> that I will never publish, but that's a separate issue. The point is\n> that all my tags will always be published here.\n\nMakes sense. The variable is to name such a publishing location.\n\n> - branch.implicit-push.remote set to ram, because this is the correct\n> upstream for the implicit-push branch.\n\nIf \"implicit-push\" branch at \"ram\" is updated by other people and\nyou may have to pull back from, you would need this for \"git pull\"\n(without arguments) while on that branch, I guess. But I got the\nimpression from your scenario that \"ram\" won't be updated by anybody\nbut you.\n\nSo I am guessing that this may not be needed.\n\n> - branch.implicit-push-next.remote set to peff, because this is the\n> correct upstream for the implicit-push-next branch.\n\nMakes sense. You are building on top of his work.\n\n> - branch.implicit-push-next.pushremote set to null**, because I will\n> never want to push this branch.\n\nThis becomes necessary only if you use push.default set to \"current\"\n(or \"upstream\"). If you mistakenly say \"git push\" (no other\narguments), without this configuration you will end up pushing the\nbranch out.\n\nWith \"matching\", because \"ram\" would not have this branch (you\ndecided not to publish it), \"git push\" on this branch won't push it\nout.\n\nIt may be that adding push.default=current-but-do-not-create-anew\ncould help. It is a cross between 'matching' and 'current', to say\n\"consider pushing out the current one, but only when the other side\nalready has one\", and may help people who do not \"batch\".\n\n> (Note that branch.implicit-push.pushremote is unnecessary because\n> remote.pushdefault takes care of that)\n\nTrue.\n"},{"id":"214106","messageId":"7v4nfbcs6h.fsf@alter.siamese.dyndns.org","threadId":"33218","inReplyTo":"20130410185958.GA22394@sigill.intra.peff.net","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-12T22:14:46Z","receivedAt":"2013-04-12T22:14:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> Which is still kind of weird, because why should the branch you are on\n> affect the default push location? But that is how default \"matching\" has\n> always behaved, and we would remain consistent with that.\n\nI agree that what makes us behave \"kind of weird\" is that the\ncurrent branch is used to look up branch.$name.{remote,pushremote}\nwhen pushing. I do not think \"matching\" [*1*] has anything to do\nwith it.\n\nThe per-branch configuration, branch.$name.{remote,pushremote}, says\n\"this branch interacts with a remote that is different from what I\nnormally interact with\".\n\nIt is excusable for branch.$name.remote to take the current branch\ninto account, when it is used to govern the fetch-integrate side\n(i.e. not used as a fall-back for branch.$name.pushremote). In\norder to affect that configured local branch, e.g. \"git pull\" to\nmerge other's work, you need to have that named branch checked out\nin your working tree. Triggering the effect of the configuration\nbased on which branch is checked out makes more sense because of\nthat reason when you are fetching.\n\nIt does not make much sense to use the current branch as the key to\nlook it up when you are pushing things out. If anything, what is\nbeing pushed out should be what determines where it goes.\n\nBut that is a realization that comes after you think the issue long\nand hard enough. To a casual end user, I think it is an equally or\neven more natural expectation a \"git push\" would pick the destination\nbased on what branch you are currently on, as that is what happens\nwhen he runs the command without any argument.\n\n\n[Footnote]\n\n*1* The \"matching\" semantics is to support the workflow for people\nwho batch things up. You perfect _all_ your branches that matter to\nthe public, and push all of them in one go. If you do not finish a\nwork on one branch and push out when other branches are not yet\nready, you do not want your push to be limited to the current\nbranch. And you do not have to \"configure\" what branches should be\nvisible to the public. Instead, you have _your_ remote remember it\nfor you: what are already there are the ones that are updated.\n\nThe \"current\", \"upstream\", etc. are to support folks who want to\npush work done on a single branch out as soon as it is done, even\nthough the other branches are in no shape to be pushed out.\n"},{"id":"214123","messageId":"CALkWK0=qigG40C7Htv0Yt6ZrgP+vgsauRe=2rWuAuq7UJ47rfw@mail.gmail.com","threadId":"33218","inReplyTo":"7vppy0hhk7.fsf@alter.siamese.dyndns.org","subject":"Re: [ITCH] Specify refspec without remote","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-13T05:07:56Z","receivedAt":"2013-04-13T05:07:56Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n> When pushing into other kinds of repositories (e.g. you can update\n> some but not all of the branches, or you want to touch only some of\n> them and not others even if you have enough privilege to update any\n> of them) or when you do not \"batch\" and push out one branch as work\n> on it is done, while other branches that you would eventually\n> publish are still not ready, \"matching\" is not for you.\n\nI agree that we need to get a \"batching\" push.default corresponding to\n\"matching\" for multiple-remote setups. However, I think we should\nhold it off until my implicit-push patch is finished. After using it\nfor a few days, I'll get a good idea about what this new push.default\nsetting should look like.\n\n> If \"implicit-push\" branch at \"ram\" is updated by other people and\n> you may have to pull back from, you would need this for \"git pull\"\n> (without arguments) while on that branch, I guess. But I got the\n> impression from your scenario that \"ram\" won't be updated by anybody\n> but you.\n>\n> So I am guessing that this may not be needed.\n\nIn my opinion, it is a fundamental mistake to have more than one\nperson working on a branch. There is one exception to this rule: it\nis alright when there are only two people working on it, and one of\nthem is a \"reliable fast-forward-only read-only upstream\". Let me\nillustrate this with an example: I sometimes find myself working on\nthe master branch of git.git (fetch from origin: git/git.git, publish\nto ram: artagnon/git.git). This is because origin/master is an\n\"reliable fast-forward-only read-only upstream\" (read-only in the\nsense that it can only be updated with a git fetch). My interaction\nwith it is limited to 'git rebase origin/master' on the master branch.\n I will never find myself manipulating it, and the rebase will never\nfail unless my patches conflict with the new upstream.\n\nAs to why the setting is needed: I often work on more than one device*,\nand I suspect a lot of people do this today. I always fetch all\nchanges on my private branches before beginning work, unless I want to\nend up in a confusing mess (I often rewrite history).\n\n> This becomes necessary only if you use push.default set to \"current\"\n> (or \"upstream\"). If you mistakenly say \"git push\" (no other\n> arguments), without this configuration you will end up pushing the\n> branch out.\n\nRight. The objective is to get 'git push' to _always_ DTRT.\n\n> It may be that adding push.default=current-but-do-not-create-anew\n> could help. It is a cross between 'matching' and 'current', to say\n> \"consider pushing out the current one, but only when the other side\n> already has one\", and may help people who do not \"batch\".\n\nHm. I would argue that exploding push.default options is unhealthy,\nand that we should move towards thinking of more fine-grained control\nwith different orthogonal options. I'll first do it for pull\n(autostash has been in progress for some time); then we can port the\nrelevant options to push.\n\n* I still haven't made much progress on a design for config-sharing. I\nthink I'm missing something big.\n"}]}