{"thread":{"id":"34049","subject":"branch.<name>.pushremote not working with push.default simple or upstream","startedAt":"2013-06-07T12:41:47Z","lastAt":"2013-06-07T18:34:20Z","messageCount":9,"participants":["Leandro Lucarella","Ramkumar Ramachandra","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"219625","messageId":"20130607124146.GF28668@sociomantic.com","threadId":"34049","inReplyTo":null,"subject":"branch.<name>.pushremote not working with push.default simple or upstream","fromName":"Leandro Lucarella","fromEmail":"leandro.lucarella@sociomantic.com","sentAt":"2013-06-07T12:41:47Z","receivedAt":"2013-06-07T12:41:47Z","isPatch":false,"sender":{"key":"leandro.lucarella@sociomantic.com","avatar":"https://gravatar.com/avatar/b8884950a0d028195af6bb849af0136915e795824f1d888a9599af7ce3d174af?d=mp&s=160"},"body":"Hi, I tried to use the new Git feature to push by default to a different\nremote you normally pull but I had some problems. I asked in the #git\nIRC channel and been told it looks like a bug and to report it here.\n\nI have 2 remotes, origin and upstream. origin is my private fork (and I\ncan push to it) while upstream is read-only for me. I have only one\nbranch, 'master' (present in all the remotes), originally tracking\norigin/master.\n\nI changed branch.master.remote to upstream and set\nbranch.master.pushremote to origin, but when I do I git push I get an\nerror:\n\n$ git push --dry-run --verbose\nfatal: You are pushing to remote 'origin', which is not the upstream of\nyour current branch 'master', without telling me what to push\nto update which remote branch.\n\nI'm using push.default 'simple' to stay forward compatible with Git 2.0.\nIn the IRC channel they suggested to try with other push.default\nsettings and I did. 'matching' and 'current' works, but 'simple' and\n'upstream' fail with the error message above.\n\nThank you.\n\n-- \nLeandro Lucarella\nSenior R&D Developer\nsociomantic labs GmbH <http://www.sociomantic.com>\n"},{"id":"219629","messageId":"CALkWK0miONv_O67SHcfJoXq1x7xPvKu6uefg+TiPGbF-1WJ-bg@mail.gmail.com","threadId":"34049","inReplyTo":"20130607124146.GF28668@sociomantic.com","subject":"Re: branch.<name>.pushremote not working with push.default simple or upstream","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-06-07T14:11:07Z","receivedAt":"2013-06-07T14:11:07Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"[+CC: jc, jk]\n\nLeandro Lucarella wrote:\n> I changed branch.master.remote to upstream and set\n> branch.master.pushremote to origin, but when I do I git push I get an\n> error:\n>\n> $ git push --dry-run --verbose\n> fatal: You are pushing to remote 'origin', which is not the upstream of\n> your current branch 'master', without telling me what to push\n> to update which remote branch.\n\nYes, this is a defect: both remote.pushdefault and\nbranch.<name>.pushremote suffer from it.\n\nLet me explain what's happening.  The error is triggered off in\nsetup_push_upstream() in builtin/push.c (which both simple and\nupstream use).  It's exactly the same error that will be reported if\nyou do the following without a branch.master.pushremote or\nremote.pushdefault configured:\n\n  $ git push origin --dry-run --verbose\n  fatal: You are pushing to remote 'origin', which is not the upstream of\n  your current branch 'master', without telling me what to push\n  to update which remote branch.\n\nYou should therefore be able to infer that remote.pushdefault/\nbranch.<name>.pushremote is simply saving you from remembering/ typing\nout that \"origin\" on the command-line.  The error precisely describes\nthe problem.  To understand what this \"upstream\" the error is talking\nabout, see:\n\n   $ git rev-parse --symbolic-full-name @{u}\n   refs/remotes/upstream/master\n\nSo, if you are pushing to upstream, the push knows what to do: push to\nthe refspec <branch>:<branch>@{u} (see builtin/push.c:148).  If you're\npushing to origin, it has no idea _what_ to push, and hence errors\nout.  By design, upstream/ simple assume that you push to the same\nplace that you pull from: the description clearly says that it is\nintended to make the push and pull symmetric.\n\nFinally, the reason remote.pushdefault/ branch.<name>.pushremote works\nin the other modes is simple: in matching and current, the push\nrefspec is not dependent on the current branch's upstream.  In\nmatching, the refspec it is the constant \":\", and in current, it is\nthe constant \"HEAD\" (will subtly change with rr/push-head).\n\nI think the correct fix is to change the semantics of upstream/simple\nto dictate a refspec independent of remote.  So, if:\n\n1. branch.master.merge is configured to refs/heads/rr/master\n2. branch.master.remote is configured to origin\n3. remote.pushdefault is configured to ram\n4. push.default is configured to upstream\n\nThen, the a push should push the refspec master:rr/master to the\nremote ram.  Let's see what the others have to say before proceeding.\n\nThank you for reporting this problem.  It is indeed very serious,\nespecially since simple is going to be default in Git 2.0.\n"},{"id":"219641","messageId":"7v8v2lvs5s.fsf@alter.siamese.dyndns.org","threadId":"34049","inReplyTo":"CALkWK0miONv_O67SHcfJoXq1x7xPvKu6uefg+TiPGbF-1WJ-bg@mail.gmail.com","subject":"Re: branch.<name>.pushremote not working with push.default simple or upstream","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-06-07T15:47:59Z","receivedAt":"2013-06-07T15:47:59Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra <artagnon@gmail.com> writes:\n\n> [+CC: jc, jk]\n>\n> Leandro Lucarella wrote:\n>> I changed branch.master.remote to upstream and set\n>> branch.master.pushremote to origin, but when I do I git push I get an\n>> error:\n>>\n>> $ git push --dry-run --verbose\n>> fatal: You are pushing to remote 'origin', which is not the upstream of\n>> your current branch 'master', without telling me what to push\n>> to update which remote branch.\n>\n> Yes, this is a defect: both remote.pushdefault and\n> branch.<name>.pushremote suffer from it.\n\nThe upstream and simple modes have been defined to push to\n\"upstream\" repository in central-shared-repository workflow.\n\nAt this point in Leandro's example, I think the configuration is:\n\n\t[branch \"master\"]\n\t\tremote = upstream\n                merge = refs/heads/master\n                pushremote = origin\n\nand master@{u} == upstream's master, not origin's.\n\nThis shows the \"triangular\" support in 1.8.3 is only half-finished;\nthe other half was discussed a few weeks ago ($gmane/224604), but I\ndo not recall what the current status of the topic is.  I personally\nthink 'single' the root level of the thread hints is an overkill\nmechanism, so here is a suggestion to show one possible way forward.\n\nUntil the branch.$name.push mechanism is introduced to specify which\ndestination branch is updated by the push, and/or branch.$name.push\nis not specified after such a mechanism is introduced, I think the\nnatural extension of the current end-user configuration would be to\nredefine \"upstream\" mode to push to update the branch with the same\nname (in the above example, 'master' of 'origin' is updated), when\nthe \"repository that is pushed to, which is different from the\nrepository that is fetched from\" is specified via remote.pushdefault\nor branch.$name.pushremote mechanisms.\n\nThis incidentally covers \"simple\" mode, because \"pushing to update\nthe branch with the same name\" is the only behaviour accepted by the\nmode anyway.\n\nWhen branch.$name.push mechanism is introduced and the user uses it,\nthen \"upstream\", \"simple\", or any other setting for that matter\nwould be ignored.  With\n\n\t[branch \"master\"]\n\t\tremote = upstream\n                merge = refs/heads/master\n                pushremote = origin\n\t\tpush = refs/heads/master\n\nit is clear that \"git push\" while on 'master' should push to origin\nto update its master branch.\n"},{"id":"219645","messageId":"20130607161402.GH28668@sociomantic.com","threadId":"34049","inReplyTo":"7v8v2lvs5s.fsf@alter.siamese.dyndns.org","subject":"Re: branch.<name>.pushremote not working with push.default simple or upstream","fromName":"Leandro Lucarella","fromEmail":"leandro.lucarella@sociomantic.com","sentAt":"2013-06-07T16:14:02Z","receivedAt":"2013-06-07T16:14:02Z","isPatch":false,"sender":{"key":"leandro.lucarella@sociomantic.com","avatar":"https://gravatar.com/avatar/b8884950a0d028195af6bb849af0136915e795824f1d888a9599af7ce3d174af?d=mp&s=160"},"body":"On Fri, Jun 07, 2013 at 08:47:59AM -0700, Junio C Hamano wrote:\n> When branch.$name.push mechanism is introduced and the user uses it,\n> then \"upstream\", \"simple\", or any other setting for that matter\n> would be ignored.  With\n> \n> \t[branch \"master\"]\n> \t\tremote = upstream\n>                 merge = refs/heads/master\n>                 pushremote = origin\n> \t\tpush = refs/heads/master\n> \n> it is clear that \"git push\" while on 'master' should push to origin\n> to update its master branch.\n\nThanks for the detailed explanations, I think this would cover my use\ncase. Just for clarification, here are some more details on this use\ncase, which I think is becoming very popular among github users.\nWe have a \"blessed\" repository (upstream in my case) and only a few\npeople is able to push to it (let's call them maintainers). Every\ndeveloper, including the ones with push access, have to go through peer\nreviewing and are not allowed to push their own commits to upstream. For\npeer reviewing, each have it's own public fork, that other people can\nreview and merge/push if is good.\n\nIn this scheme, you always pull from the blessed repository and only\npush to your personal fork, with the exceptions of the maintainers that\nneed to push from time to time other people pull requests.\n\nMy ideal would be to be able to just do 'git pull' to get the new stuff\nand 'git push' to push to my fork. Since pushing to the blessed\nrepository is more \"critical\", is perfect that I need to explicitly push\nto it with 'git push upstream master'.\n\nThank you.\n\n-- \nLeandro Lucarella\nSenior R&D Developer\nsociomantic labs GmbH <http://www.sociomantic.com>\n"},{"id":"219647","messageId":"CALkWK0m0QDGVUmHkmzC7G6it9fJafQCh8+423-NOyMwq9yts1Q@mail.gmail.com","threadId":"34049","inReplyTo":"7v8v2lvs5s.fsf@alter.siamese.dyndns.org","subject":"Re: branch.<name>.pushremote not working with push.default simple or upstream","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-06-07T16:51:41Z","receivedAt":"2013-06-07T16:51:41Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n> This shows the \"triangular\" support in 1.8.3 is only half-finished;\n> the other half was discussed a few weeks ago ($gmane/224604)\n\nI intentionally omitted that detail, because it is not directly\nrelated to this bug.  We have to fix the existing simple and upstream,\nwhether or not we introduce branch.<name>.push.  I've personally\nstopped working on branch.<name>.push, and am focusing on getting @{p}\nfirst (you've already seen a dirty wip).  The transport code\nunderlying the push is dirty enough, and I'd first like to understand\nit before bolting on more features.\n\n> I think the\n> natural extension of the current end-user configuration would be to\n> redefine \"upstream\" mode to push to update the branch with the same\n> name\n\nRight, so does this work?\n\ndiff --git a/builtin/push.c b/builtin/push.c\nindex 2d84d10..b253a64 100644\n--- a/builtin/push.c\n+++ b/builtin/push.c\n@@ -137,11 +137,6 @@ static void setup_push_upstream(struct remote\n \tif (branch->merge_nr != 1)\n \t\tdie(_(\"The current branch %s has multiple upstream branches, \"\n \t\t    \"refusing to push.\"), branch->name);\n-\tif (strcmp(branch->remote_name, remote->name))\n-\t\tdie(_(\"You are pushing to remote '%s', which is not the upstream of\\n\"\n-\t\t      \"your current branch '%s', without telling me what to push\\n\"\n-\t\t      \"to update which remote branch.\"),\n-\t\t    remote->name, branch->name);\n \tif (simple && strcmp(branch->refname, branch->merge[0]->src))\n \t\tdie_push_simple(branch, remote);\n"},{"id":"219648","messageId":"CALkWK0=v2vF7oGG3yUAXfaGdodCrkbvmQA+z9hMcoeMUFGFgsg@mail.gmail.com","threadId":"34049","inReplyTo":"20130607161402.GH28668@sociomantic.com","subject":"Re: branch.<name>.pushremote not working with push.default simple or upstream","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-06-07T16:57:58Z","receivedAt":"2013-06-07T16:57:58Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Leandro Lucarella wrote:\n> Thanks for the detailed explanations, I think this would cover my use\n> case. Just for clarification, here are some more details on this use\n> case, which I think is becoming very popular among github users.\n> We have a \"blessed\" repository (upstream in my case) and only a few\n> people is able to push to it (let's call them maintainers). Every\n> developer, including the ones with push access, have to go through peer\n> reviewing and are not allowed to push their own commits to upstream. For\n> peer reviewing, each have it's own public fork, that other people can\n> review and merge/push if is good.\n\nYes, and I wrote it precisely to address this itch.  git/git is\norigin, and artagnon/git is ram.  I just set remote.pushdefault to ram\nand continue working as usual.\n\nI apologize for not having thought hard enough about other\npush.default modes: I personally use current, and like it very much.\nAs an added bonus, even new branches created with git checkout -b\nhot-branch will get push to go to the right place; no need to set\nupstream before pushing.\n"},{"id":"219651","messageId":"20130607170752.GI28668@sociomantic.com","threadId":"34049","inReplyTo":"CALkWK0=v2vF7oGG3yUAXfaGdodCrkbvmQA+z9hMcoeMUFGFgsg@mail.gmail.com","subject":"Re: branch.<name>.pushremote not working with push.default simple or upstream","fromName":"Leandro Lucarella","fromEmail":"leandro.lucarella@sociomantic.com","sentAt":"2013-06-07T17:07:52Z","receivedAt":"2013-06-07T17:07:52Z","isPatch":false,"sender":{"key":"leandro.lucarella@sociomantic.com","avatar":"https://gravatar.com/avatar/b8884950a0d028195af6bb849af0136915e795824f1d888a9599af7ce3d174af?d=mp&s=160"},"body":"On Fri, Jun 07, 2013 at 10:27:58PM +0530, Ramkumar Ramachandra wrote:\n> Leandro Lucarella wrote:\n> > Thanks for the detailed explanations, I think this would cover my use\n> > case. Just for clarification, here are some more details on this use\n> > case, which I think is becoming very popular among github users.\n> > We have a \"blessed\" repository (upstream in my case) and only a few\n> > people is able to push to it (let's call them maintainers). Every\n> > developer, including the ones with push access, have to go through peer\n> > reviewing and are not allowed to push their own commits to upstream. For\n> > peer reviewing, each have it's own public fork, that other people can\n> > review and merge/push if is good.\n> \n> Yes, and I wrote it precisely to address this itch.  git/git is\n> origin, and artagnon/git is ram.  I just set remote.pushdefault to ram\n> and continue working as usual.\n> \n> I apologize for not having thought hard enough about other\n> push.default modes: I personally use current, and like it very much.\n> As an added bonus, even new branches created with git checkout -b\n> hot-branch will get push to go to the right place; no need to set\n> upstream before pushing.\n\nI might try to just switch to current, I feel more comfortable with\nsimple because I feel is safer to explicitly set the upstream branch,\nbut is true that most of the time is not necessary.\n\n-- \nLeandro Lucarella\nSenior R&D Developer\nsociomantic labs GmbH <http://www.sociomantic.com>\n"},{"id":"219654","messageId":"CALkWK0=FnZUBXMJjSKgrbunDn3TtME-1tw++B5FimJx5=K_1qQ@mail.gmail.com","threadId":"34049","inReplyTo":"20130607170752.GI28668@sociomantic.com","subject":"Re: branch.<name>.pushremote not working with push.default simple or upstream","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-06-07T17:33:56Z","receivedAt":"2013-06-07T17:33:56Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Leandro Lucarella wrote:\n> I might try to just switch to current, I feel more comfortable with\n> simple because I feel is safer to explicitly set the upstream branch,\n> but is true that most of the time is not necessary.\n\nBe more experimental!  Use the lesser-known features, and tell us\nabout breakages: that's how you can help git improve :)\n"},{"id":"219663","messageId":"7vhah9u5w3.fsf@alter.siamese.dyndns.org","threadId":"34049","inReplyTo":"CALkWK0m0QDGVUmHkmzC7G6it9fJafQCh8+423-NOyMwq9yts1Q@mail.gmail.com","subject":"Re: branch.<name>.pushremote not working with push.default simple or upstream","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-06-07T18:34:20Z","receivedAt":"2013-06-07T18:34:20Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra <artagnon@gmail.com> writes:\n\n> Junio C Hamano wrote:\n>> This shows the \"triangular\" support in 1.8.3 is only half-finished;\n>> the other half was discussed a few weeks ago ($gmane/224604)\n>\n> I intentionally omitted that detail, because it is not directly\n> related to this bug.  We have to fix the existing simple and upstream,\n> whether or not we introduce branch.<name>.push.  I've personally\n> stopped working on branch.<name>.push, and am focusing on getting @{p}\n> first (you've already seen a dirty wip).  The transport code\n> underlying the push is dirty enough, and I'd first like to understand\n> it before bolting on more features.\n>\n>> I think the\n>> natural extension of the current end-user configuration would be to\n>> redefine \"upstream\" mode to push to update the branch with the same\n>> name\n>\n> Right, so does this work?\n\nIt might be a beginning of a change in the right direction (I didn't\ncheck the codeflow), but given that the test that comes after the\none you removed is looking at branch->merge[0] and deciding what to\ndo, and branch.$name.merge should *never* affect anything when\nremote.pushdefault or branch.$name.pushremote is in use while\ndeciding what is pushed out or if the push is allowed, I do not\nthink the removal of these five lines alone can possibly \"work\".\n\n> diff --git a/builtin/push.c b/builtin/push.c\n> index 2d84d10..b253a64 100644\n> --- a/builtin/push.c\n> +++ b/builtin/push.c\n> @@ -137,11 +137,6 @@ static void setup_push_upstream(struct remote\n>  \tif (branch->merge_nr != 1)\n>  \t\tdie(_(\"The current branch %s has multiple upstream branches, \"\n>  \t\t    \"refusing to push.\"), branch->name);\n> -\tif (strcmp(branch->remote_name, remote->name))\n> -\t\tdie(_(\"You are pushing to remote '%s', which is not the upstream of\\n\"\n> -\t\t      \"your current branch '%s', without telling me what to push\\n\"\n> -\t\t      \"to update which remote branch.\"),\n> -\t\t    remote->name, branch->name);\n>  \tif (simple && strcmp(branch->refname, branch->merge[0]->src))\n>  \t\tdie_push_simple(branch, remote);\n"}]}