1
$ git branch
  master
* portal
$ git fetch
$ git merge origin/portal
Already up-to-date.
$ git pull
Already up-to-date.
$ git push
To git@github.com:ripper234/Commerce-Sciences.git
 ! [rejected]        master -> master (non-fast-forward)
error: failed to push some refs to 'git@github.com:ripper234/Commerce-Sciences.git'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes (e.g. 'git pull') before pushing again.  See the
'Note about fast-forwards' section of 'git push --help' for details.

Normally I would do a gitk -all to try and see what the hell is going on, but this is on a linux box without a graphical shell.

ripper234
  • 222,824
  • 274
  • 634
  • 905
  • possible duplicate of [Git push complaining about non-fast-forward, even though remote has been pulled](http://stackoverflow.com/questions/5723714/git-push-complaining-about-non-fast-forward-even-though-remote-has-been-pulled) – ripper234 Jan 16 '12 at 09:55
  • 1
    A handy terminal-only alternative to `gitk --all` is `git log --oneline --graph --decorate --all` – Mark Longair Jan 16 '12 at 10:06

1 Answers1

5

Note this line from the error message:

! [rejected]        master -> master (non-fast-forward)

You merged the portal branches, but you're also trying to push master, since git push will by default try to push all branches which also exist on origin. Try this:

$ git push origin portal
hammar
  • 138,522
  • 17
  • 304
  • 385
  • But I am already on `portal` branch ... doesn't `git push` push the current branch? – ripper234 Jan 16 '12 at 10:00
  • It turned out the `portal` branch didn't have any commits that were not already pushed. I'm still confused. – ripper234 Jan 16 '12 at 10:02
  • 3
    @ripper234: `git push` pushes every branch to one with a matching name in the remote *so long as a branch with that name already exists on the remote side*. If you want to change that behaviour to a less surprising one, look at the documentation for the `push.default` config option. – Mark Longair Jan 16 '12 at 10:04
  • But how can a branch like that not exist in my case ... I don't understand. The branch was created on machine A, pushed into github, pulled into machine B, and subsequently a push was attempted from B into github. No funny stuff, all defaults. How can a remote branch not exist already in this case? – ripper234 Jan 16 '12 at 10:08
  • Also, I have successfully pushed this branch before from machine B into github. Not sure what was different this time. – ripper234 Jan 16 '12 at 10:08
  • 2
    @ripper234: If `portal` exists in `origin`, I would *guess* that the behaviour of `git push` is to stop after the failure to push `master -> master`. In general it's much safer to always specify the branch you want to push or set `push.default` to `tracking`. – Mark Longair Jan 16 '12 at 10:19
  • 1
    @MarkLongair - thanks for the clarification. `upstream` should be used instead of `tracking` (deprecated synonym). Now that I understand the situation, I think I'll keep the default behavior - I actually want `git push` to "backup" all my local changes. http://stackoverflow.com/questions/948354/git-push-current-branch – ripper234 Jan 16 '12 at 10:45