Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

git pushing commit shows error: unable to push to unqualified destination

Tags:

git

bash

I'm trying to push head commit to remote with WIP- showing error like

$ git push remote 51447424149c671958a2f76ec1fefb135a5c2cea:WIP-51447424149c671958a2f76ec1fefb135a5c2cea

[which results in]

error: unable to push to unqualified destination: WIP-51447424149c671958a2f76ec1fefb135a5c2cea
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 'https://github.com/abc'

Any help ?

like image 509
user3423907 Avatar asked Jan 23 '18 17:01

user3423907


People also ask

How do I fix git error failed to push some refs to?

We can fix the error: failed to push some refs to [remote repo] error in Git using the git pull origin [branch] or git pull --rebase origin [branch] commands. In most cases, the latter fixes the error.

How do I enable push in git?

In your repository's right sidebar, click Settings. Click the "Collaborators" tab. Start typing the collaborator's username. Select the user from the drop-down menu.

What is push to origin?

Git push origin is usually used only where there are multiple remote repositories and you want to specify which remote repository should be used for the push. For a git push origin command: git push command updates remote references using local references by sending objects necessary to complete the given references.


1 Answers

TL;DR

You probably wanted:

$ git push remote 51447424149c671958a2f76ec1fefb135a5c2cea:refs/heads/WIP-51447424149c671958a2f76ec1fefb135a5c2cea

to create a branch named WIP-51447424149c671958a2f76ec1fefb135a5c2cea. (Be sure you really want to create that name, as it's kind of unweildy. It's valid and there is no problem with it, it's just a heck of a thing to type in.)

Long

What Git is complaining about takes a little bit of explanation:

  • A branch name is a special form of reference.
  • A reference is a string starting with refs/. The familiar two kinds of references are branch names and tags. (More about this in just a moment.)
  • References can be abbreviated ... sometimes, but not always.
  • Sometimes (wherever it makes sense to Git) you can use a raw hash ID instead of a reference.
  • git push takes a refspec, which is a pair of references separated by a colon (and optionally the whole thing can be prefixed with a plus sign).

What you're doing with git push is using the (very long) refspec 51447424149c671958a2f76ec1fefb135a5c2cea:WIP-51447424149c671958a2f76ec1fefb135a5c2cea. The left side of this refspec is the source reference, and the right side is the destination reference.

The thing on the left side of the colon is clearly1 a hash ID. So this is making use of the special case where you can supply a hash ID instead of an actual reference (as long as that object actually exists in your Git repository).

The thing on the right side of the colon, though, is a name, not a hash ID. This is good since this is one of the places that Git requires a name. But it's also a problem, because the name WIP-something does not start with refs/.

Note that Git explicitly complains about that:

The destination ... nor begins with refs/

Before we get to the rest, let's mention branches and tags again. A branch name like master is short-hand for the reference refs/heads/master. A tag name like v1.2 is short-hand for the reference refs/tags/v1.2. Note that in both cases, these start with refs/. They go on to name which kind of reference we're using:

  • A branch name reference starts with refs/heads/.
  • A tag name reference starts with refs/tags/.

In other words, when we say that branches and tags are forms of references, we're saying that given a reference, you can look at what comes right after refs/ and figure out what kind of reference it is: refs/heads/ means "branch" and refs/tags/ means "tag". (If you see refs/remotes/, that means it's a remote-tracking name; and there are yet more special words that go after refs/, such as notes/ for git notes.)

We also said above that references can sometimes be abbreviated. That's the first part of what Git is complaining about here, though:

... neither matches an existing ref on the remote ...

You're allowed to leave out the refs/heads/ part, and have the other Git—the one that your Git is pushing-to—figure out that master really means refs/heads/master. But this only works if they already have a refs/heads/master. If you're trying to create a new branch, you must tell the other Git: I'd like you to create a new branch.

You do this by giving the full name of the reference: refs/heads/WIP-something, for instance. The fact that it starts with refs/heads/ tells the other Git: I'd like to create a branch name. If you send them refs/tags/WIP-something, you are telling them to create a new tag name.

Anyway, this is why you're getting the rather long complaint, with its two parts: "neither ... nor". So the solution is to send them the full name.


1What, isn't it obvious? :-) This reminds me of the professors who prove theorems by doing six transformations and then saying "the rest is obvious...".

like image 167
torek Avatar answered Sep 24 '22 10:09

torek