284

I had a repository that had some bad commits on it (D, E and F for this example).

A-B-C-D-E-F master and origin/master

I've modified the local repository specifically with a git reset --hard. I took a branch before the reset so now I have a repo that looks like:

A-B-C master \ D-E-F old_master A-B-C-D-E-F origin/master

Now I needed some parts of those bad commits so I cherry picked the bits I needed and made some new commits so now I have the following locally:

A-B-C-G-H master \ D-E-F old_master

Now I want to push this state of affairs to the remote repo. However, when I try to do a git push Git politely gives me the brush off:

$ git push origin +master:master --force Total 0 (delta 0), reused 0 (delta 0) error: denying non-fast forward refs/heads/master (you should pull first) To [email protected]:myrepo.git ! [remote rejected] master -> master (non-fast forward) error: failed to push some refs to '[email protected]:myrepo.git'

How do I get the remote repo to take the current state of the local repo?

Improve this question
3
  • 2
    The is an 'almost' duplicate of several "how do I push amended history questions", e.g. see the answer here stackoverflow.com/questions/253055/… Commented Sep 4, 2009 at 8:26
  • 2
    That's true and I had searched StackOverflow for an answer before posting. However my search had only turned up answers in which a git push --force fixed the issue. Thanks for linking to your post :) Commented Sep 4, 2009 at 8:52
  • 2
    You will soon (git1.8.5, Q4 2013) be able to do a git push -force more carefully. Commented Sep 10, 2013 at 8:42

5 Answers 5

Reset to default
355

If forcing a push doesn't help (git push --force origin or git push --force origin master should be enough), it might mean that the remote server is refusing non fast-forward pushes, via either receive.denyNonFastForwards config variable (see git config manpage for description), or via an update/pre-receive hook.

With older Git you can work around that restriction by deleting git push origin :master (note the : before branch name) and then re-creating git push origin master given branch.

If you can't change this, then the only solution would be instead of rewriting history to create a commit reverting changes in D-E-F:

A-B-C-D-E-F-[(D-E-F)^-1] master A-B-C-D-E-F origin/master
Improve this answer
Sign up to request clarification or add additional context in comments.

2 Comments

@JakubNarębski, thanks. get revert HEAD~N helped. N is the number of commits. E.g., if I need the previous commit, I'll use git revert HEAD~1
And be aware you will break everybody else local master by doing this.
55

For users of GitHub, this worked for me:

  1. In any branch protection rules where you wish to make the change, make sure Allow force pushes is enabled
  2. git reset --hard <full_hash_of_commit_to_reset_to>
  3. git push --force

This will "correct" the branch history on your local machine and the GitHub server, but anyone who has sync'ed this branch with the server since the bad commit will have the history on their local machine. If they have permission to push to the branch directly then these commits will show right back up when they sync.

All everyone else needs to do is the git reset command from above to "correct" the branch on their local machine. Of course they would need to be wary of any local commits made to this branch after the target hash. Cherry pick/backup and reapply those as necessary, but if you are in a protected branch then the number of people who can commit directly to it is likely limited.

Improve this answer

2 Comments

Ditto for Gitlab: if you have a nasty message like "error: failed to push some refs to http://www.gitlab.com/me/myproject" the problem may be that you need to "allow forced push": Settings --> Repository --> Protected branches (at time of writing). No need to actually unprotect the branch, but do allow forced push. I actually did a pull on the branch in question, then a hard reset, then a forced push.
Works perfectly with bitbucket too, thanks.
28

To complement Jakub's answer, if you have access to the remote git server in ssh, you can go into the git remote directory and set:

user@remote$ git config receive.denyNonFastforwards false

Then go back to your local repo, try again to do your commit with --force:

user@local$ git push origin +master:master --force

And finally revert the server's setting in the original protected state:

user@remote$ git config receive.denyNonFastforwards true
Improve this answer

2 Comments

See also pete.akeo.ie/2011/02/denying-non-fast-forward-and.html for sourceforge tailored information about this.
Detailed instructions on how to disable denyNonFastForwards using vi are provided on this SO post: stackoverflow.com/a/43721579/2073804
3

Instead of fixing your "master" branch, it's way easier to swap it with your "desired-master" by renaming the branches. See https://stackoverflow.com/a/2862606/2321594. This way you wouldn't even leave any trace of multiple revert logs.

Improve this answer

Comments

2

The whole git resetting business looked far to complicating for me.

So I did something along the lines to get my src folder in the state i had a few commits ago

# reset the local state git reset <somecommit> --hard # copy the relevant part e.g. src (exclude is only needed if you specify .) tar cvfz /tmp/current.tgz --exclude .git src # get the current state of git git pull # remove what you don't like anymore rm -rf src # restore from the tar file tar xvfz /tmp/current.tgz # commit everything back to git git commit -a # now you can properly push git push

This way the state of affairs in the src is kept in a tar file and git is forced to accept this state without too much fiddling basically the src directory is replaced with the state it had several commits ago.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.