{"thread":{"id":"27263","subject":"error with $ git push origin HEAD:newbranch","startedAt":"2011-05-05T08:47:39Z","lastAt":"2011-05-11T10:10:01Z","messageCount":11,"participants":["chris","Jeff King","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"167095","messageId":"loom.20110505T103708-225@post.gmane.org","threadId":"27263","inReplyTo":null,"subject":"error with $ git push origin HEAD:newbranch","fromName":"chris","fromEmail":"jugg@hotmail.com","sentAt":"2011-05-05T08:47:39Z","receivedAt":"2011-05-05T08:47:39Z","isPatch":false,"sender":{"key":"jugg@hotmail.com","avatar":null},"body":"$ git push origin HEAD:newbranch\nerror: unable to push to unqualified destination: newbranch\nThe destination refspec neither matches an existing ref on the remote nor\nbegins with refs/, and we are unable to guess a prefix based on the source ref.\nerror: failed to push some refs to 'ssh://example.com/srv/git/project.git'\n\nThis worked previously[1]. Local git version 1.7.5, remote git version 1.7.2.3.\n\n1. I recently upgraded locally from 1.7.4.x\n"},{"id":"167100","messageId":"20110505093752.GB29595@sigill.intra.peff.net","threadId":"27263","inReplyTo":"loom.20110505T103708-225@post.gmane.org","subject":"Re: error with $ git push origin HEAD:newbranch","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-05-05T09:37:52Z","receivedAt":"2011-05-05T09:37:52Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, May 05, 2011 at 08:47:39AM +0000, chris wrote:\n\n> $ git push origin HEAD:newbranch\n> error: unable to push to unqualified destination: newbranch\n> The destination refspec neither matches an existing ref on the remote nor\n> begins with refs/, and we are unable to guess a prefix based on the source ref.\n> error: failed to push some refs to 'ssh://example.com/srv/git/project.git'\n> \n> This worked previously[1]. Local git version 1.7.5, remote git version 1.7.2.3.\n> \n> 1. I recently upgraded locally from 1.7.4.x\n\nI can't replicate here, using this snippet:\n\n git init --bare parent &&\n git clone parent child &&\n (cd child &&\n echo content >file &&\n git add file &&\n git commit -m one &&\n git push origin HEAD:newbranch\n )\n\nHowever, you may see that message if you are on a detached head instead\nof a branch. Might that be the case here?\n\n-Peff\n"},{"id":"167101","messageId":"loom.20110505T114511-660@post.gmane.org","threadId":"27263","inReplyTo":"20110505093752.GB29595@sigill.intra.peff.net","subject":"Re: error with $ git push origin HEAD:newbranch","fromName":"chris","fromEmail":"jugg@hotmail.com","sentAt":"2011-05-05T10:06:21Z","receivedAt":"2011-05-05T10:06:21Z","isPatch":false,"sender":{"key":"jugg@hotmail.com","avatar":null},"body":"Jeff King peff.net> writes:\n> On Thu, May 05, 2011 at 08:47:39AM +0000, chris wrote:\n> \n> > $ git push origin HEAD:newbranch\n> > error: unable to push to unqualified destination: newbranch\n> > The destination refspec neither matches an existing ref on the remote nor\n> > begins with refs/, and we are unable to guess a prefix based on the source \nref.\n> > error: failed to push some refs to 'ssh://example.com/srv/git/project.git'\n> > \n... \n> However, you may see that message if you are on a detached head instead\n> of a branch. Might that be the case here?\n\nYes, indeed. I suppose it must be the situation that I've never done that\nbefore then. While I certainly I have pushed a detached head before, it must \nhave always been to an existing branch.\n\nThanks for clarifying this.\n\nIt is slightly surprising that git-push doesn't default to assuming one means \nrefs/heads/newbranch in this case. I don't see a reason not to?\n\nchris\n"},{"id":"167102","messageId":"20110505105914.GA464@sigill.intra.peff.net","threadId":"27263","inReplyTo":"loom.20110505T114511-660@post.gmane.org","subject":"Re: error with $ git push origin HEAD:newbranch","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-05-05T10:59:14Z","receivedAt":"2011-05-05T10:59:14Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, May 05, 2011 at 10:06:21AM +0000, chris wrote:\n\n> Yes, indeed. I suppose it must be the situation that I've never done that\n> before then. While I certainly I have pushed a detached head before, it must \n> have always been to an existing branch.\n> \n> Thanks for clarifying this.\n> \n> It is slightly surprising that git-push doesn't default to assuming one means \n> refs/heads/newbranch in this case. I don't see a reason not to?\n\nConsider something like:\n\n $ git checkout v1.5\n $ git push origin HEAD:foo\n\nWould you want \"foo\" to be a branch or a tag? I can see arguments for\neither.\n\nRather than trying to guess, it's fairly easy to disambiguate. For a\nbranch, either:\n\n $ git push origin HEAD:refs/heads/foo\n\nor\n\n $ git branch foo\n $ git push origin HEAD\n\nwould work, depending on whether or not you want a local branch.\n\n-Peff\n"},{"id":"167207","messageId":"loom.20110506T034552-210@post.gmane.org","threadId":"27263","inReplyTo":"20110505105914.GA464@sigill.intra.peff.net","subject":"Re: error with $ git push origin HEAD:newbranch","fromName":"chris","fromEmail":"jugg@hotmail.com","sentAt":"2011-05-06T02:16:03Z","receivedAt":"2011-05-06T02:16:03Z","isPatch":false,"sender":{"key":"jugg@hotmail.com","avatar":null},"body":"Jeff King peff.net> writes:\n> \n> On Thu, May 05, 2011 at 10:06:21AM +0000, chris wrote:\n> \n> > It is slightly surprising that git-push doesn't default to assuming \n> > one means refs/heads/newbranch in this case. I don't see a reason \n> > not to?\n> \n> Consider something like:\n> \n> $ git checkout v1.5\n> $ git push origin HEAD:foo\n> \n> Would you want \"foo\" to be a branch or a tag? I can see arguments for\n> either.\n\nIf the above command wanted to produce a tag, just provide 'v1.5' as the source \nref. It seems to me that first checking out the tag then pushing from HEAD is \nextra steps in order to push a branch ref without having to be explicit about \nit. $ git push origin v1.5:foo would have been simpler if intending to push a \ntag ref.\n\nGiven that git-push has specific syntax for pushing a tag, and git-push makes \nother assumptions that give the perception it is generally used for branches \nunless told otherwise also makes me expect that \"foo\" to be a branch.\n\nThe following is provided for specifically calling out a tag:\n\n $ git push origin tag \n\nHowever, that syntax as far as I can tell is pretty worthless anyway, as the \nfollowing will not work:\n\n $ git push origin tag HEAD:newtag\n error: src refspec refs/tags/HEAD does not match any.\n\n $ git push origin tag 183c65e:newtag\n error: src refspec refs/tags/183c65e does not match any.\n\nBut both the following are successful, which makes me ask why the 'tag' option \nexists if the above doesn't work.\n\n $ git push tag existingtag:newtag1\n\n $ git push existingtag:newtag2\n\nSo I see little purpose in the $ git push tag syntax, as the source \nmust already be a tag anyway.\n\nAll of that to say, it isn't exactly clear what one should expect.\n\nPersonally, I would prefer that git-push work on branches by default[1], \nproviding shortcuts for pushing tag[2] refs and remote branch[3] refs, while all \nother ref types must be called out explicitly. Creating new refs isn't \ndestructive, so it seems these could be supported without concern.\n\n1. $ git push origin SHA1:branch1\n => $ git push origin SHA1:refs/heads/branch1\n\n2. $ git push origin tag SHA1:tagname\n => $ git push origin SHA1:refs/tags/tagname\n\n3. $ git push origin SHA1:upstream/branch2\n => $ git push origin SHA1:refs/remotes/upstream/branch2\n\nchris\n"},{"id":"167214","messageId":"7v39ks4ebd.fsf@alter.siamese.dyndns.org","threadId":"27263","inReplyTo":"loom.20110506T034552-210@post.gmane.org","subject":"Re: error with $ git push origin HEAD:newbranch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-05-06T04:56:38Z","receivedAt":"2011-05-06T04:56:38Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"chris writes:\n\n> All of that to say, it isn't exactly clear what one should expect.\n\nThe take-home lesson is that if you want to be explicit and exactly clear,\nyou can and should spell things out in full, and you can sleep well at\nnight if you did so.\n\n\t# Let's call retroactively v1.5 without the last three topic\n # merges the v1.4.9 release...\n\t$ git push origin v1.5~3:refs/tags/v1.4.9\n"},{"id":"167221","messageId":"loom.20110506T081810-948@post.gmane.org","threadId":"27263","inReplyTo":"7v39ks4ebd.fsf@alter.siamese.dyndns.org","subject":"Re: error with $ git push origin HEAD:newbranch","fromName":"chris","fromEmail":"jugg@hotmail.com","sentAt":"2011-05-06T06:35:51Z","receivedAt":"2011-05-06T06:35:51Z","isPatch":false,"sender":{"key":"jugg@hotmail.com","avatar":null},"body":"Junio C Hamano pobox.com> writes:\n> \n> chris hotmail.com> writes:\n> \n> > All of that to say, it isn't exactly clear what one should expect.\n> \n> The take-home lesson is that if you want to be explicit and exactly clear,\n> you can and should spell things out in full, and you can sleep well at\n> night if you did so.\n\nYes, in order to be clear, one should be explicit. But that was never in \nquestion here. The discussion revolved around the non-explicit refspec usage \nwith git-push.\n\nAnd certainly there seems to have been attempts in the past to provide sensible \nshort-hand usage for the command, but it would appear the accumulation lacks \nconsistency. If the expectation is that one should always be explicit, then I \nassume the short-hand will begin to become deprecated? If not, then discussing \nit and improving it where possible seems rather acceptable.\n\nchris\n"},{"id":"167264","messageId":"20110506170204.GA16576@sigill.intra.peff.net","threadId":"27263","inReplyTo":"loom.20110506T034552-210@post.gmane.org","subject":"Re: error with $ git push origin HEAD:newbranch","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-05-06T17:02:04Z","receivedAt":"2011-05-06T17:02:04Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, May 06, 2011 at 02:16:03AM +0000, chris wrote:\n\n> Jeff King peff.net> writes:\n> > \n> > On Thu, May 05, 2011 at 10:06:21AM +0000, chris wrote:\n> > \n> > > It is slightly surprising that git-push doesn't default to assuming \n> > > one means refs/heads/newbranch in this case. I don't see a reason \n> > > not to?\n> > \n> > Consider something like:\n> > \n> > $ git checkout v1.5\n> > $ git push origin HEAD:foo\n> > \n> > Would you want \"foo\" to be a branch or a tag? I can see arguments for\n> > either.\n> \n> If the above command wanted to produce a tag, just provide 'v1.5' as the source \n> ref. It seems to me that first checking out the tag then pushing from HEAD is \n> extra steps in order to push a branch ref without having to be explicit about \n> it. $ git push origin v1.5:foo would have been simpler if intending to push a \n> tag ref.\n\nSure, but that was just a small example. It could just as easily have\nbeen:\n\n $ git checkout v1.5\n ... look look look ...\n ... hmm, this one doesn't have the bug or feature I'm looking for ...\n $ git checkout v1.5.1\n ... look look look ...\n ... nor this one ...\n $ git checkout v1.5.2\n ... look look look ...\n ... oh, this one has it, let's push it upstream to communicate to\n somebody ...\n $ git push origin HEAD:foo\n\nSure, I _could_ say \"git push origin v1.5.2:foo\" in the final step. But\nmy mental model is \"I have found the thing I am looking for, now push\nit\", which means HEAD is more natural. This is more obvious to see when\nyou start leaving refs, like:\n\n $ git checkout HEAD^\n ... look look look; nope ...\n $ git checkout HEAD^\n ... look look look; nope ...\n $ git checkout HEAD^\n ... yep, found it ...\n $ git push origin HEAD:foo\n\nSo in both of those cases, what should be pushed? A tag or a branch? My\nargument is that git would have to guess. Rather than guess, we come\nback to the user and say \"please be more specific\".\n\n> Given that git-push has specific syntax for pushing a tag, and git-push makes \n> other assumptions that give the perception it is generally used for branches \n> unless told otherwise also makes me expect that \"foo\" to be a branch.\n\nThat tag syntax is antique and predates most of the nice DWIM behavior\nof refspecs. Nowadays you can just say \"git push v1.5\" and it\nwill do the same thing without the \"tag\" modifier. So I doubt anyone\nuses it.\n\nI wonder if we should more clearly mark it as useless in the\ndocumentation.\n\n> The following is provided for specifically calling out a tag:\n> \n> $ git push origin tag \n> \n> However, that syntax as far as I can tell is pretty worthless anyway, as the \n> following will not work:\n> \n> $ git push origin tag HEAD:newtag\n> error: src refspec refs/tags/HEAD does not match any.\n> \n> $ git push origin tag 183c65e:newtag\n> error: src refspec refs/tags/183c65e does not match any.\n\nRight. It's literally about expanding \"tag foo\" into\n\"refs/tags/foo:refs/tags/foo\". So it only works for a tag ref.\n\nFor both of those, you would need:\n\n git push origin HEAD:refs/tags/newtag\n\n git push origin 183c65e:refs/tags/newtag\n\n> But both the following are successful, which makes me ask why the 'tag' option \n> exists if the above doesn't work.\n> \n> $ git push tag existingtag:newtag1\n> \n> $ git push existingtag:newtag2\n> \n> So I see little purpose in the $ git push tag syntax, as the source \n> must already be a tag anyway.\n\nRight. Once upon a time, that didn't Just Work. These days we see that\nthe LHS of the refspec is a tag, and infer that the RHS should be, as\nwell (in the absence of anything more specific).\n\n> Personally, I would prefer that git-push work on branches by default[1], \n> providing shortcuts for pushing tag[2] refs and remote branch[3] refs, while all \n> other ref types must be called out explicitly. Creating new refs isn't \n> destructive, so it seems these could be supported without concern.\n> \n> 1. $ git push origin SHA1:branch1\n> => $ git push origin SHA1:refs/heads/branch1\n> \n> 2. $ git push origin tag SHA1:tagname\n> => $ git push origin SHA1:refs/tags/tagname\n> \n> 3. $ git push origin SHA1:upstream/branch2\n> => $ git push origin SHA1:refs/remotes/upstream/branch2\n\nIn (3), how do you differentiate between the branch\n\"refs/heads/upstream/branch2\" and the remote tracking branch\n\"refs/remotes/upstream/branches\"?\n\n-Peff\n"},{"id":"167604","messageId":"loom.20110510T153328-584@post.gmane.org","threadId":"27263","inReplyTo":"20110506170204.GA16576@sigill.intra.peff.net","subject":"Re: error with $ git push origin HEAD:newbranch","fromName":"chris","fromEmail":"jugg@hotmail.com","sentAt":"2011-05-10T15:34:26Z","receivedAt":"2011-05-10T15:34:26Z","isPatch":false,"sender":{"key":"jugg@hotmail.com","avatar":null},"body":"Jeff King peff.net> writes:\n> \n> On Fri, May 06, 2011 at 02:16:03AM +0000, chris wrote:\n> \n> > Personally, I would prefer that git-push work on branches by default[1], \n> > providing shortcuts for pushing tag[2] refs and remote branch[3] refs, \n> > while all other ref types must be called out explicitly. Creating new refs \n> > isn't destructive, so it seems these could be supported without concern.\n> > \n> > 1. $ git push origin SHA1:branch1\n> > => $ git push origin SHA1:refs/heads/branch1\n> > \n> > 2. $ git push origin tag SHA1:tagname\n> > => $ git push origin SHA1:refs/tags/tagname\n> > \n> > 3. $ git push origin SHA1:upstream/branch2\n> > => $ git push origin SHA1:refs/remotes/upstream/branch2\n> \n> In (3), how do you differentiate between the branch\n> \"refs/heads/upstream/branch2\" and the remote tracking branch\n> \"refs/remotes/upstream/branches\"?\n\nI was just taking a queue from the documentation:\n\n--\n\"git push origin master:satellite/master dev:satellite/dev\n\nUse the source ref that matches master (e.g. refs/heads/master) to update the\nref that matches satellite/master (most probably refs/remotes/satellite/master)\nin the origin repository, then do the same for dev and satellite/dev.\"\n--\n\nOf course the documentation there is meaninging that\nrefs/remotes/satellite/master already exists and that there is no conflicting\nrefs/heads/satellite/master.\n\nProbably what I need to do is better understand the \"guess work\" git-push\nalready does before trying to \"improve\" it. So, based on this thread and the\ndocumentation, the following holds true:\n\n $ git push origin HEAD:newbranch\n\nis valid only if HEAD contains a branch ref pointer. Otherwise, if the LHS of\nthe refspec is not a known ref type, the RHS must always be explicit when\npushing a new ref. If the LHS is a known ref type, then the same ref type is\nused for the RHS of the refspec - also the RHS becomes optional in such a case\nand the LHS name will be used if the RHS was omitted.\n\nIf that is a correct summary (something missing?), then as is, there is little\npoint in anything but explicit specification of the RHS of the refspec when\npushing a new ref.\n\nAnd given that \"$ git push remote tag \" syntax seems to be outdated, I\ndon't see any benefit to my proposed set of shortcuts for pushing new refs.\n\nSo, thanks Peff for the informative responses, they helped bring my\nunderstanding up a notch.\n\nchris\n"},{"id":"167616","messageId":"20110510194738.GB14456@sigill.intra.peff.net","threadId":"27263","inReplyTo":"loom.20110510T153328-584@post.gmane.org","subject":"Re: error with $ git push origin HEAD:newbranch","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-05-10T19:47:38Z","receivedAt":"2011-05-10T19:47:38Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, May 10, 2011 at 03:34:26PM +0000, chris wrote:\n\n> I was just taking a queue from the documentation:\n> \n> --\n> \"git push origin master:satellite/master dev:satellite/dev\n> \n> Use the source ref that matches master (e.g. refs/heads/master) to update the\n> ref that matches satellite/master (most probably refs/remotes/satellite/master)\n> in the origin repository, then do the same for dev and satellite/dev.\"\n> --\n> \n> Of course the documentation there is meaninging that\n> refs/remotes/satellite/master already exists and that there is no conflicting\n> refs/heads/satellite/master.\n\nRight. All of our discussion has been on the case where the RHS doesn't\nmatch anything on the remote.\n\n> Probably what I need to do is better understand the \"guess work\" git-push\n> already does before trying to \"improve\" it. So, based on this thread and the\n> documentation, the following holds true:\n> \n> $ git push origin HEAD:newbranch\n> \n> is valid only if HEAD contains a branch ref pointer. Otherwise, if the LHS of\n> the refspec is not a known ref type, the RHS must always be explicit when\n> pushing a new ref. If the LHS is a known ref type, then the same ref type is\n> used for the RHS of the refspec - also the RHS becomes optional in such a case\n> and the LHS name will be used if the RHS was omitted.\n\nI think the RHS is always optional, isn't it? That is, if I say:\n\n git push origin foo\n\nthen that is always equivalent to\n\n git push origin foo:foo\n\nwhich will then push to the matching \"foo\" on the remote; if it does not\nexist, then it will infer the type of \"foo\" on the remote from the type\nof \"foo\" locally. But I could be mis-remembering, as it's been a while\nsince I've dug into the refspec code.\n\nOther than that, I think your description above is accurate.\n\n-Peff\n"},{"id":"167679","messageId":"loom.20110511T040830-212@post.gmane.org","threadId":"27263","inReplyTo":"20110510194738.GB14456@sigill.intra.peff.net","subject":"Re: error with $ git push origin HEAD:newbranch","fromName":"chris","fromEmail":"jugg@hotmail.com","sentAt":"2011-05-11T10:10:01Z","receivedAt":"2011-05-11T10:10:01Z","isPatch":false,"sender":{"key":"jugg@hotmail.com","avatar":null},"body":"Jeff King peff.net> writes:\n> \n> On Tue, May 10, 2011 at 03:34:26PM +0000, chris wrote:\n> \n> > \n> > $ git push origin HEAD:newbranch\n> > \n> > is valid only if HEAD contains a branch ref pointer. Otherwise, if the \n> > LHS of the refspec is not a known ref type, the RHS must always be \n> > explicit when pushing a new ref. If the LHS is a known ref type, then \n> > the same ref type is used for the RHS of the refspec - also the RHS \n> > becomes optional in such a case and the LHS name will be used if the RHS \n> > was omitted.\n> \n> I think the RHS is always optional, isn't it? That is, if I say:\n> \n> git push origin foo\n> \n> then that is always equivalent to\n> \n> git push origin foo:foo\n> \n> which will then push to the matching \"foo\" on the remote; if it does not\n> exist, then it will infer the type of \"foo\" on the remote from the type\n> of \"foo\" locally. But I could be mis-remembering, as it's been a while\n> since I've dug into the refspec code.\n\nYes, but I was distinguishing when the LHS is not a known ref type\n\n $ git push origin HEAD^\n\nisn't valid. So, my meaning was RHS only becomes optional if the LHS resolves \nto a local ref. Which may be obvious; I was just trying to cover the use cases.\n\nI think the generalization is that git-push tries to build the refspec using \nhints from the local ref part. If it can not do so, it fails rather than \ndefaulting to any particular behavior.\n\nchris\n"}]}