3

In push following errors occured

git.exe push    "origin" master:master

To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes before pushing again.  See the 'non-fast forward'
section of 'git push --help' for details.
To //oht-fsv1/Source/Git/Test
! [rejected]        master -> master (non-fast forward)

What's wrong?

freddiefujiwara
  • 57,041
  • 28
  • 76
  • 106

1 Answers1

7

From git push:

When an update changes a branch (or more in general, a ref) that used to point at commit A to point at another commit B, it is called a fast-forward update if and only if B is a descendant of A.

In a fast-forward update from A to B, the set of commits that the original commit A built on top of is a subset of the commits the new commit B builds on top of. Hence, it does not lose any history.

In contrast, a non-fast-forward update will lose history.

So this will prevent you to lose history: try a git pull first, resolve potential conflicts, and "git push" the result.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • I have just come across this error,so how can I prevent the git pull from overwriting my current changes. I tried the git pull thing before, and it overwrote my latest changes and left me pretty confused. How will the conflicts be detected? – vfclists Apr 01 '11 at 07:16
  • @vfclists: `git pull` should simply "overwrite" your changes, but merge the upstreams modification on top of your changes. You also have (if you haven't pushed your local modifications yet) `git pull --rebase` which will merge your modification on top of the updated upstream branch. – VonC Apr 01 '11 at 07:49
  • @VonC if I do the git pull, can I simply do a `git checkout lastcommit filename` on the files I last committed locally to fix the issue? Will that be accepted? How can I check the remote for the commits which caused the fast forward, in case they came from other checkouts in different locations? I am certain what I am working on is the only one pushing to it. – vfclists Apr 01 '11 at 08:58
  • @vfclists: beware of a `git checkout -- filename`: it is really an operation which really overwrite (not merge) changes. A `git pull --rebase` in your case is much safer. – VonC Apr 01 '11 at 09:04
  • What if `git pull ` says 'already up to date' and git push gives the same problem. That's what i'm facing – Adil Jun 09 '11 at 08:49
  • @Adil: "already up to date" always make me think of a "detached HEAD" situation: http://stackoverflow.com/questions/999907/git-push-says-everything-up-to-date-even-though-i-have-local-changes/1000009#1000009 and http://stackoverflow.com/questions/5772192/git-how-can-i-reconcile-detached-head-with-master-origin/5772882#5772882 . Would that be the case here for you? – VonC Jun 09 '11 at 10:08
  • That's exactly it VonC. I figured it was an incomplete rebase. Unfortunately i had to manually redo some changes after i figured i'm on no branch! Thanks for the links. – Adil Jun 09 '11 at 11:16