funny refname error when creating a new remote branch

Question

So I've gotten a project up on github and everything is dandy. Now I want to create a new branch.

Here's what I've done:

1. created a new local branch
2. pushed the new branch to github

Here's the problem: During the push to my remote, I get this error:

Repository ssh://[email protected]/<username>/ProjectColossus.git

funny refname
error: refusing to create funny ref 'workingBranch' remotely

My remote repo is called origin, so I've tried using that refname as suggested in another answer here on stackoverflow, but I get the same error. I've also tried using the same name as my new local branch, in the "Target Ref Name:" field before the remote push, but I really just am not sure what I'm doing at this point. I know there's something I'm not getting about git remote pushes, so a little explanation would be super helpful. I'm pretty new to git and version control, but I'm an intermediate level programmer (starting second year CS in January).

Abreaction

What command have you run? git push origin workingBranch:workingBranch? I don't see why this branch name would be considered funny. – Rugger

Please provide the exact command you tried. – Yuletide

I'm using egit, so there's no command line for me. – Abreaction

I've never used egit, but I suspect that it's this code returning the error. And given that the branch name looks fine, it's probably because it's not being push to refs/heads. If there's an option about where to push, you could try refs/heads/workingBranch. – Hooke

@jszakmeister Yeah that's what I ended up doing.. I'm not sure what refs/heads/ means, but I prefixed it to the new branch name and it worked. – Abreaction

@ScubaSteve The Pro Git book can be useful here. It describes how refs work, and the Git User's Manual talks about them too. Basically, all refs do is point at a commit. Branches are under refs/heads, tags are under refs/tags, and remotes go under refs/remotes. So refs/heads/workingBranch refers to a branch. – Hooke

@jszakmeister ahh yeah that clears it up a bit.. much obliged! – Abreaction

Answer 1

In the Target Ref Name, probably you have to add refs/heads:

refs/heads/name_of_your_new_branch

In your specific case:

refs/heads/workingBranch

(at least, it is the way with Bitbucket - egit, the Eclipse plugin for Eclipse)

Savaii

forgot about this question.. but yup.. pretty much how i solved it – Abreaction

Answer 2

I find it a litle bit silly that EGit expects something like V0.0.1 when you create a Tag (placing the tag to /refs/tags/V0.0.1 location in the local repository) and it expects to provide the refname like /refs/tags/V0.0.1 when you push the Tag into the remote repository

Aneurysm

My experience with EGit is that it's quite fussy. Hell, all of Eclipse is fussy. I'm a .Net dev now, and it's a world of difference. – Abreaction

Answer 3

For what it is worth we just had this issue - we are using VS2013 and creating a branch with /refs/heads/ gave an error. We ended up downloading Source Tree from Atlassian (we are using Stash to house our code). This showed an "uncommited change" which was the DesignTimeResolveAssemblyReferencesInput.cache file being altered - something VS2013 was doing. We undid this change and created a new branch, and this solved the problem.

Hopefully this will point somebody in the right direction if the above methods do not work.

Chet

Answer 4

That error (error: refusing to create funny ref) should be when you create a branch with a "funny" ref.

But Git 2.41 (Q2 2023) now allow the deletion of such ref: "git push"^(man) has been taught to allow deletion of refs with one-level names to help to repair a repository who acquired such a ref by mistake.

In general, we don't encourage use of such a ref, and creation or update to such a ref is rejected as before.

Now Eclipse uses JGit, a pure Java library implementing the Git version control system. But if you create such a branch, you can use Git itself, from command-line, to remove it.

See commit 7c3c550, commit d81ba50 (01 Mar 2023) by ZheNing Hu (adlternative).
^{(Merged by Junio C Hamano -- gitster -- in commit 4a25b91, 19 Mar 2023)}

push: allow delete single-level ref

^{Signed-off-by: ZheNing Hu}

We discourage the creation/update of single-level refs because some upper-layer applications only work in specified reference namespaces, such as "refs/heads/*" or "refs/tags/*", these single-level refnames may not be recognized.
However, we still hope users can delete them which have been created by mistake.

Therefore, when updating branches on the server with "git receive-pack"^(man), by checking whether it is a branch deletion operation, it will determine whether to allow the update of a single-level refs.

This avoids creating/updating such single-level refs, but allows them to be deleted.

On the client side, "git push"^(man) also does not properly fill in the old-oid of single-level refs, which causes the server-side "git receive-pack" to think that the refs old-oid has changed when deleting single-level refs, this causes the push to be rejected.
So the solution is to fix the client to be able to delete single-level refs by properly filling old-oid.

Merissameristem