error with $ git push origin HEAD:newbranch

$ git push origin HEAD:newbranch error: unable to push to unqualified destination: newbranch The destination refspec neither matches an existing ref on the remote nor begins with refs/, and we are unable to guess a prefix based on the source ref. error: failed to push some refs to 'ssh://example.com/srv/git/project.git'

This worked previously[1].  Local git version 1.7.5, remote git version 1.7.2.3.

1. I recently upgraded locally from 1.7.4.x

On Thu, May 05, 2011 at 08:47:39AM +0000, chris wrote:

I can't replicate here, using this snippet:

  git init --bare parent &&
  git clone parent child &&
  (cd child &&
   echo content >file &&
   git add file &&
   git commit -m one &&
   git push origin HEAD:newbranch
  )

However, you may see that message if you are on a detached head instead of a branch. Might that be the case here?

-Peff

Jeff King <peff <at> peff.net> writes:

ref.

... 

Yes, indeed. I suppose it must be the situation that I've never done that before then. While I certainly I have pushed a detached head before, it must have always been to an existing branch.

Thanks for clarifying this.

It is slightly surprising that git-push doesn't default to assuming one means refs/heads/newbranch in this case. I don't see a reason not to?

chris

On Thu, May 05, 2011 at 10:06:21AM +0000, chris wrote:

Consider something like:

  $ git checkout v1.5
  $ git push origin HEAD:foo

Would you want "foo" to be a branch or a tag? I can see arguments for either.

Rather than trying to guess, it's fairly easy to disambiguate. For a branch, either:

  $ git push origin HEAD:refs/heads/foo

or

  $ git branch foo
  $ git push origin HEAD

would work, depending on whether or not you want a local branch.

-Peff

Jeff King <peff <at> peff.net> writes:

If the above command wanted to produce a tag, just provide 'v1.5' as the source ref. It seems to me that first checking out the tag then pushing from HEAD is extra steps in order to push a branch ref without having to be explicit about it. $ git push origin v1.5:foo would have been simpler if intending to push a tag ref.

Given that git-push has specific syntax for pushing a tag, and git-push makes other assumptions that give the perception it is generally used for branches unless told otherwise also makes me expect that "foo" to be a branch.

The following is provided for specifically calling out a tag:

  $ git push origin tag <refspec>

However, that syntax as far as I can tell is pretty worthless anyway, as the following will not work:

  $ git push origin tag HEAD:newtag
  error: src refspec refs/tags/HEAD does not match any.

  $ git push origin tag 183c65e:newtag
  error: src refspec refs/tags/183c65e does not match any.

But both the following are successful, which makes me ask why the 'tag' option exists if the above doesn't work.

  $ git push tag existingtag:newtag1

  $ git push existingtag:newtag2

So I see little purpose in the $ git push tag <refspec> syntax, as the source must already be a tag anyway.

All of that to say, it isn't exactly clear what one should expect.

Personally, I would prefer that git-push work on branches by default[1], providing shortcuts for pushing tag[2] refs and remote branch[3] refs, while all other ref types must be called out explicitly. Creating new refs isn't destructive, so it seems these could be supported without concern.

1. $ git push origin SHA1:branch1
  => $ git push origin SHA1:refs/heads/branch1

2. $ git push origin tag SHA1:tagname
  => $ git push origin SHA1:refs/tags/tagname

3. $ git push origin SHA1:upstream/branch2
  => $ git push origin SHA1:refs/remotes/upstream/branch2

chris

chris <jugg@hotmail.com> writes:

The take-home lesson is that if you want to be explicit and exactly clear, you can and should spell things out in full, and you can sleep well at night if you did so.

	# Let's call retroactively v1.5 without the last three topic
        # merges the v1.4.9 release...
	$ git push origin v1.5~3:refs/tags/v1.4.9

Junio C Hamano <gitster <at> pobox.com> writes:

Yes, in order to be clear, one should be explicit. But that was never in question here. The discussion revolved around the non-explicit refspec usage with git-push.

And certainly there seems to have been attempts in the past to provide sensible short-hand usage for the command, but it would appear the accumulation lacks consistency. If the expectation is that one should always be explicit, then I assume the short-hand will begin to become deprecated? If not, then discussing it and improving it where possible seems rather acceptable.

chris

On Fri, May 06, 2011 at 02:16:03AM +0000, chris wrote:

Sure, but that was just a small example. It could just as easily have been:

  $ git checkout v1.5
  ... look look look ...
  ... hmm, this one doesn't have the bug or feature I'm looking for ...
  $ git checkout v1.5.1
  ... look look look ...
  ... nor this one ...
  $ git checkout v1.5.2
  ... look look look ...
  ... oh, this one has it, let's push it upstream to communicate to
      somebody ...
  $ git push origin HEAD:foo

Sure, I _could_ say "git push origin v1.5.2:foo" in the final step. But my mental model is "I have found the thing I am looking for, now push it", which means HEAD is more natural. This is more obvious to see when you start leaving refs, like:

  $ git checkout HEAD^
  ... look look look; nope ...
  $ git checkout HEAD^
  ... look look look; nope ...
  $ git checkout HEAD^
  ... yep, found it ...
  $ git push origin HEAD:foo

So in both of those cases, what should be pushed? A tag or a branch? My argument is that git would have to guess. Rather than guess, we come back to the user and say "please be more specific".

That tag syntax is antique and predates most of the nice DWIM behavior of refspecs. Nowadays you can just say "git push <remote> v1.5" and it will do the same thing without the "tag" modifier. So I doubt anyone uses it.

I wonder if we should more clearly mark it as useless in the documentation.

Right. It's literally about expanding "tag foo" into "refs/tags/foo:refs/tags/foo". So it only works for a tag ref.

For both of those, you would need:

  git push origin HEAD:refs/tags/newtag

  git push origin 183c65e:refs/tags/newtag

Right. Once upon a time, that didn't Just Work. These days we see that the LHS of the refspec is a tag, and infer that the RHS should be, as well (in the absence of anything more specific).

In (3), how do you differentiate between the branch "refs/heads/upstream/branch2" and the remote tracking branch "refs/remotes/upstream/branches"?

-Peff

Jeff King <peff <at> peff.net> writes:

I was just taking a queue from the documentation:

-- "git push origin master:satellite/master dev:satellite/dev

Use the source ref that matches master (e.g. refs/heads/master) to update the ref that matches satellite/master (most probably refs/remotes/satellite/master) in the origin repository, then do the same for dev and satellite/dev." --

Of course the documentation there is meaninging that refs/remotes/satellite/master already exists and that there is no conflicting refs/heads/satellite/master.

Probably what I need to do is better understand the "guess work" git-push already does before trying to "improve" it. So, based on this thread and the documentation, the following holds true:

  $ git push origin HEAD:newbranch

is valid only if HEAD contains a branch ref pointer. Otherwise, if the LHS of the refspec is not a known ref type, the RHS must always be explicit when pushing a new ref. If the LHS is a known ref type, then the same ref type is used for the RHS of the refspec - also the RHS becomes optional in such a case and the LHS name will be used if the RHS was omitted.

If that is a correct summary (something missing?), then as is, there is little point in anything but explicit specification of the RHS of the refspec when pushing a new ref.

And given that "$ git push remote tag <refspec>" syntax seems to be outdated, I don't see any benefit to my proposed set of shortcuts for pushing new refs.

So, thanks Peff for the informative responses, they helped bring my understanding up a notch.

chris

On Tue, May 10, 2011 at 03:34:26PM +0000, chris wrote:

Right. All of our discussion has been on the case where the RHS doesn't match anything on the remote.

I think the RHS is always optional, isn't it? That is, if I say:

  git push origin foo

then that is always equivalent to

  git push origin foo:foo

which will then push to the matching "foo" on the remote; if it does not exist, then it will infer the type of "foo" on the remote from the type of "foo" locally. But I could be mis-remembering, as it's been a while since I've dug into the refspec code.

Other than that, I think your description above is accurate.

-Peff

Jeff King <peff <at> peff.net> writes:

Yes, but I was distinguishing when the LHS is not a known ref type

  $ git push origin HEAD^

isn't valid. So, my meaning was RHS only becomes optional if the LHS resolves to a local ref. Which may be obvious; I was just trying to cover the use cases.

I think the generalization is that git-push tries to build the refspec using hints from the local ref part. If it can not do so, it fails rather than defaulting to any particular behavior.

chris