error with $ git push origin HEAD:newbranch

error with $ git push origin HEAD:newbranch

[chris]

$ 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

Re: error with $ git push origin HEAD:newbranch

[Jeff King]

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

> $ 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

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

Re: error with $ git push origin HEAD:newbranch

[chris]

Jeff King <peff <at> peff.net> writes:
> On Thu, May 05, 2011 at 08:47:39AM +0000, chris wrote:
> 
> > $ 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'
> > 
... 
> However, you may see that message if you are on a detached head instead
> of a branch. Might that be the case here?

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

Re: error with $ git push origin HEAD:newbranch

[Jeff King]

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

> 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?

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

Re: error with $ git push origin HEAD:newbranch

[chris]

Jeff King <peff <at> peff.net> writes:
> 
> On Thu, May 05, 2011 at 10:06:21AM +0000, chris wrote:
> 
> > 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?
> 
> 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.

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

Re: error with $ git push origin HEAD:newbranch

[Junio C Hamano]

chris <jugg@hotmail.com> writes:

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

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

Re: error with $ git push origin HEAD:newbranch

[chris]

Junio C Hamano <gitster <at> pobox.com> writes:
> 
> chris <jugg <at> hotmail.com> writes:
> 
> > All of that to say, it isn't exactly clear what one should expect.
> 
> 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.

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

Re: error with $ git push origin HEAD:newbranch

[Jeff King]

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

> Jeff King <peff <at> peff.net> writes:
> > 
> > On Thu, May 05, 2011 at 10:06:21AM +0000, chris wrote:
> > 
> > > 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?
> > 
> > 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.
> 
> 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.

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".

> 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.

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.

> 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.

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

> 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.

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).

> 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

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

-Peff

Re: error with $ git push origin HEAD:newbranch

[chris]

Jeff King <peff <at> peff.net> writes:
> 
> On Fri, May 06, 2011 at 02:16:03AM +0000, chris wrote:
> 
> > 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
> 
> In (3), how do you differentiate between the branch
> "refs/heads/upstream/branch2" and the remote tracking branch
> "refs/remotes/upstream/branches"?

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

Re: error with $ git push origin HEAD:newbranch

[Jeff King]

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

> 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.

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

> 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.

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

Re: error with $ git push origin HEAD:newbranch

[chris]

Jeff King <peff <at> peff.net> writes:
> 
> On Tue, May 10, 2011 at 03:34:26PM +0000, chris wrote:
> 
> > 
> >   $ 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.
> 
> 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.

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