"git push" silently fails, says 'Everything up-to-date" when it's not.

I *thought* I'd pushed everything from my tree out to the server a couple of weeks ago, and 'git push' appears to confirm that:

[dwmw2@shinybook mtd-2.6]$ git push Everything up-to-date

But it lies. Only when I try to *pull* does it give me a hint:

[dwmw2@shinybook mtd-2.6]$ git pull You are not currently on a branch, so I cannot use any 'branch.<branchname>.merge' in your configuration file. Please specify which branch you want to merge with on the command line and try again (e.g. 'git pull <repository> <refspec>'). See git-pull(1) for details.

So I've been happily thinking that my commits were actually in linux-next for the last couple of weeks when they weren't. OK, I could have checked in gitweb — silly me for trusting the tools.

Why would it do this evil thing and start lying to me? When it told me 'Everything up-to-date', precisely *what* was it telling me was up to date? Did it ever push *anything*, *anywhere*, or was it just a complete fabrication?

I don't quite know how I ended up "not currently on a branch" either. I almost never use branches locally and my local tree has *never* been changed to another branch; I always use separate trees instead of branches. I may have committed a few things, then reverted them with 'git reset HEAD^^^^' and re-committed them with some changes. But that shouldn't cause this, surely?

When I have a clone a remote tree, and I run 'git push', surely my HEAD should be pushed to the HEAD of the remote tree? There's little excuse for *telling* me it's up-to-date, when it's not!

I understand that some people like the branch facility even though I find it mostly pointless, but I'd prefer that it didn't undermine basic usability of git :(

David Woodhouse <dwmw2@infradead.org> writes:

What does

  git config push.default 

say?

You probably have push.default=matching, which is the default. In this mode, Git will push all your local branches to remote branches having the same name (regardless of which branch you currently have checked-out). The commits you just did were not on any branch, so they're not pushed.

It probably pushed your branches, but not commits done in detached HEAD.

Either you did "git checkout <some-commit-identifier>" (in which case you had a big fat warning), or you used one command that runs in detached HEAD like "git rebase" or "git bisect" without concluding the operation ("git bisect reset", "git rebase --continue" or so).

With a recent enough version of Git, each commit you did in detached head had this little reminder:

$ git commit -m foo
[detached HEAD acb1d5b] foo
 ^^^^^^^^^^^^^

As for the future, there's a patch serie in progress that will make "git status" warn a bit more loudly in these cases, and give you a clue about what to do next.

In Git 2.0, the push.default value will change to "simple", which errors out like this in your case:

$ git push fatal: You are not currently on a branch. To push the history leading to the current (detached HEAD) state now, use

    git push origin HEAD:<name-of-remote-branch>

If you can't wait to have this "simple" mode, you may want to set push.default=upstream (or current), which will push the current branch to its upstream (or to the one with the same name remotely).

I don't know what can be done to improve the case of detached HEAD with push.default=matching. Perhaps Git should warn when HEAD is not pushed (detached HEAD, or HEAD points to a branch that doesn't exist remotely)?

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

Please don't. For those whose workflow clearly separates local history building (checking different branches, making commits, etc.) and publishing the result (git push), "git push" is *not* a way to say "I am done with the work I have been doing on *this* branch", but is a way to say "I am done for the day, and all the branches I push out are in good order". It does not matter what branch the user happens to be on when "git push" is run for them (including me).