Take the 2-minute tour ×

So I have been working on some other branches. I then switched to master and decided to push it up to origin but it has decided no longer to work.

git push origin master results in:

[remote rejected] master -> master (no such ref)

Obviously, this is a typical meaningless Git error and I have no idea what's wrong. Any help appreciated.

Update 1

Trying to clone into a temp folder gives this:

git : warning: remote HEAD refers to nonexistent ref, unable to checkout.

Update 2

I recreated the remote repository but this time pushing hung completely before the stupid tool even wrote a single line of output to the screen! Utterly woeful.

Update 3

Recent pushes have worked. I think I'm back to where I was. Something goes badly wrong with Git each week. I would sincerely advise people to research Git problems before trying it out. I think its probably better suited to hobby work on open-source projects.

share|improve this question
Does git remote -v still show what you expect? –  alex Apr 9 '13 at 12:06
Yeah. All looks good. Except I have ... I'll update the question. –  Luke Puplett Apr 9 '13 at 12:20
These errors are only meaningless if you have not done your homework. youtu.be/ZDR433b0HJY –  TheBuzzSaw Apr 9 '13 at 15:43

2 Answers 2

... Something goes badly wrong with Git each week. ...

Many people use git and they don't have a problem with it. I don't think you can find any VCS that can handle as many commits and as often commits as happens in the the Linux kernel development. If you get a compile error every time you compile your program with gcc, then that doesn't mean gcc is broken. You get the idea.

Back to your problem, you need to be more specific in where your remote is, how is its setup etc. From the errors it seems that something bad has happened to your remote. If you are using your own server (not a well-protected place like github for example), then there could be a lot of things that can go wrong.

A very simple one could be that your hard-disk is failing, or there was a bad sector unluckily enough on your remote's git repository. If the server is running windows (not sure if git can run as a remote on windows), then your problem is that you are running windows (i.e., viruses, general windows destructiveness etc).

Now this is where git itself comes to your rescue. Let's say your remote is damaged for whatever reason. All you need to do is:

git clone --bare /path/to/your/local somewhere_else

Where somewhere_else is either on the remote (if you can do that), or somewhere in your local machine. In the later case, just copy the new clone to your remote, and change your origin to point to the new path.


Recent pushes have worked...

It sounds like the initial ssh connection (which is totally unrelated to git) took some time and you probably took it as a hang and CTRL+Ced it, while you should have waited instead. The fact that recent pushes work again shows that the problem doesn't exist any more (since the lengthy initial ssh connection has passed).

Note: rarely, I get a similar situation (my server is often github) where the remote doesn't respond for some time. I believe this is quite simply due to network problems (things like that happen all the time, for example when you are browsing the internet). Poor git is merely waiting for a response the network failed to bring him.

share|improve this answer
+1 because there's useful information but "general windows destructiveness"? I bash Git because I and some of my colleagues have terrible problems with Git, but it seems there's a ton of defensiveness around Git. People really rally round to protect its name. Why does it need protecting? Criticism leads to improvement. –  Luke Puplett Apr 11 '13 at 12:36
@LukePuplett, well you know all the problems with windows, if it doesn't break your computer, it leaves enough holes for malware to do it for you. About git, in my experience, whether with the problems I had myself or the questions I've seen here, every problem with git I saw was due to the user (sometimes myself) not understanding git, rather than a problem with git itself. That's why people defend it, because they know the problem is almost definitely not git. –  Shahbaz Apr 11 '13 at 12:52
Take the original title of this question for example: stackoverflow.com/revisions/15925079/1. It says: "one of git ls-files problems". The guy asking the question assumes there is a problem there, while in reality git is doing something completely logical. I agree that git is complicated and hard to understand, but believe me, once you do understand it, you'll realize how great it is. –  Shahbaz Apr 11 '13 at 12:54
Regarding your particular scenario, git usually does its best to ensure nothing goes wrong. However, first of all it's not a complete operating system, i.e. it relies on other tools such as ssh to handle network etc. Second, it obviously cannot defend against for example an explosion! What it did in your case is to make sure the clone that has gone bad doesn't destroy the other clones and doesn't propagate the errors around. Since it's a distributed VCS, recovering is a piece of cake. –  Shahbaz Apr 11 '13 at 12:59
I think the reason you have got a -1 is probably due to you bashing git for things that have nothing to do with it. Your question really reads like: "I hate x86 architecture because gcc is telling me it cannot cast const char * to char *". –  Shahbaz Apr 11 '13 at 13:01

Your command is wrong... You are pushing master.. Use below command

git push origin HEAD:[remote branch name]

share|improve this answer
From his first error message it is evident that he is already on master, so HEAD points to master. So your command git push origin master:master wouldn't work either, since the :master is implied. That is your command is equivalent to git push origin master. –  Shahbaz Apr 9 '13 at 13:45

Your Answer


