70

Suppose I pull changes from a git repo. Then the author of the repo force pushes to the central repo. Now I can't pull since the history is rewritten.

How can I pull the new commits (and abandon the old ones), assuming that the author force-pushed the correct version?

I know this is bad git workflow, but sometimes you can't avoid this.

Andrew Legacci
  • 1,019
  • 2
  • 9
  • 8
  • 10
    possible duplicate of [git pull after forced update](http://stackoverflow.com/questions/9813816/git-pull-after-forced-update) – Bergi Jun 09 '15 at 00:54

4 Answers4

128

Throwing away your local changes

If you want to discard your work, fetch and reset. For example, if you have a remote named origin and a branch named master:

$ git fetch origin
$ git reset --hard origin/master # Destroys your work

Keeping your local changes

If you don't want to throw away your work, you will have to do a git rebase --onto. Suppose the old origin looks like this:

A ---> B ---> C
              ^
              origin/master

And you have this:

A ---> B ---> C ---> X ---> Y ---> Z
              ^                    ^
              |                    master
              origin/master

Now, the upstream changes change things:

A ---> B ---> C ---> X ---> Y ---> Z
 \                                 ^
  ---> B'---> C'                   master
              ^          
              origin/master

You would have to run git rebase --onto origin/master <C> master, where <C> is the SHA-1 of the old origin/master branch before upstream changes. This gives you this:

A ---> B ---> C ---> X ---> Y ---> Z
 \
  ---> B'---> C'---> X'---> Y'---> Z'
              ^                    ^
              |                    master
              origin/master

Notice how B, C, X, Y, and Z are now "unreachable". They will eventually be removed from your repository by Git. In the meantime (90 days), Git will keep a copy in the reflog in case it turns out you made a mistake.

Fixing mistakes

If you git reset or git rebase wrong and accidentally lose some local changes, you can find the changes in the reflog.

In the comments, a user is suggesting git reflog expire with --expire=now but DO NOT RUN THIS COMMAND because this will DESTROY your safety net. The whole purpose of having a reflog is so that Git will sometimes save your neck when you run the wrong command.

Basically, what this command will do is immediately destroy the B, C, X, Y, and Z commits in the examples above so you can't get them back. There's no real benefit to running this command, except it might save a little bit of disk space, but Git will already purge the data after 90 days so this benefit is short-lived.

Dietrich Epp
  • 205,541
  • 37
  • 345
  • 415
  • I think `--hard` should be used with `git reset` here. – Desty Jul 04 '16 at 13:47
  • 2
    @user: I **STRONGLY RECOMMEND WITH ALL CAPS** that people do not run that command unless they want to **DESTROY THE DATA** that Git keeps as a safety net in case you run the wrong command. – Dietrich Epp Aug 02 '17 at 15:35
  • 1
    @user: That command is unnecessary. Git will do the right thing when pushing anyway. The problem is that after a `git reset --hard`, you might realize that you've just made some kind of horrible mistake and you need to get your old data back. That's what the reflog is there for, as a safety net when you make a bad `git reset`, so that is the worst possible time to irrevocably destroy the data in the reflog. – Dietrich Epp Aug 02 '17 at 15:39
  • 3
    @user: To anyone reading this comment, **DO NOT** run that command. I am not even sure what the command is trying to achieve, except **destroying** the safety net that saves your data in case you type a command wrong, such as the `git reset --hard` in the answer. Again, **DO NOT** destroy the reflog unless you are quite sure that you want to do that (again, why would you do that?) – Dietrich Epp Aug 02 '17 at 17:45
  • @user: Yes, it would have some of the same effects as destroying the repo and creating a new one... but *why would you want to do that?* Just keep using the same repo. – Dietrich Epp Aug 02 '17 at 17:46
  • Because I want to start again from fresh clone, but not wanting to delete the whole repository. I would want to start from a fresh clone, after sensitive information being removed from the cloud, so I can assure that information is anywhere on my computer or cloud. Therefore neither locally or remotely there will exists the sensitive info anymore. – Evandro Coan Aug 02 '17 at 18:14
  • If you want to erase sensitive data, that's a very different case. Most of the time, people won't need to do that. – Dietrich Epp Aug 02 '17 at 18:28
  • 2
    Point is, git isn't smart enough in this case. If someone did a force push, I assume that must have been for some reason. And if I didn't change anything on a branch after checking it out, it's fine to overwrite my branch with the changes of the origin. So, instead of trying to merge the changes resulting in conflicts, a simple `git pull` should rather be aborted when there was a forced push and the user should have an option to do a force pull in this case. – Sebastian Zartner Jul 09 '18 at 09:43
  • Would `$ git fetch origin master $ git reset --hard origin/master` work as well? – Steve Ebersole Nov 13 '20 at 16:50
  • Yes, the only difference is that `fetch origin master` won't fetch other branches. – Dietrich Epp Nov 13 '20 at 18:56
  • In My case , this was exactly what i wanted. I had made a mistake by pushing broken code to my repo. So i had to force push a previous version. And now this is the solution to getting that commit to my local code. – SHikha Mittal Sep 21 '21 at 03:46
  • How does git know that C' is an updated version of C and not an unrelated commit? If git doesn't know that C' and C are related, I would expect to see the following outcome after rebase: A -> B' -> C' -> B" -> C" -> X' -> Y' -> Z' (with B" and C" the result of applying the original B and C to the update origin). This would result very likely in merge conflicts. – m7913d Dec 20 '21 at 21:13
  • 1
    @m7913d: As far as Git is concerned, C and C' **are** unrelated commits. That's why both C and C' must be specified in the command-line arguments for the `git rebase` command (note that `origin/master` is just another name for C' here). – Dietrich Epp Dec 21 '21 at 03:23
  • Thanks for the clarification. However, note that I think git is able (in some circumstances) to relate C and C' automatically as described in [the manual](https://git-scm.com/book/en/v2/Git-Branching-Rebasing#_rebase_rebase), but specifying the commits to be rebased explicitly may be safer. – m7913d Dec 21 '21 at 16:00
1

if have NO local commits, this will recover your checkout from a force push. You will be up to date with the remote branch, and can commit your local work later.

git fetch
git stash
git reset --hard origin/master # destroys your work
git stash pop # restores your work as local changes
git mergetool # fix any conflicts

At this point you have your local changes as they were before. Your checkout is up to date with all the changes on master, or whatever branch you are working from.

rickfoosusa
  • 1,061
  • 19
  • 26
  • Rather than stashing, I would feel more comfortable committing my local changes then doing an interactive rebase onto `origin/branch`. – Marc L. Aug 11 '23 at 21:35
0

I came across a slightly modified version of this scenario. Here's what I did:

Initial condition

A--->B--->C--->D--->E
                    |
             local-1/master

A--->B--->C--->D--->E
                    |
              origin/master

A--->B--->C--->D--->E
                    |
             local-2/master

Squash and force push

A--->B--->CDE
           |
    local-1/master

A--->B--->CDE
           |
     origin/master

A--->B--->C--->D--->E
                    |
             local-2/master

Sync changes on local-2/master

$ git reset --soft B


    A--->B---> (local uncommitted changes)
         |
  local-2/master


$ git stash save "backup"


    A--->B
         |
  local-2/master

$ git pull origin master


    A--->B--->CDE
               |
        local-2/master
keyur
  • 77
  • 1
  • 6
0

If you have not made any changes to the local branch, you could try the following sequence of commands. Please remember this is a crude way to achieve what you are asking for.

git checkout master
git pull
git remote update origin -p
git branch -D myBranch
git checkout myBranch

git remote update origin -p is optional.

If you made a changes and you do not care about the contents of the local branch, you could try this:

git stash
git stash drop
git checkout master
git pull
git remote update origin -p
git branch -D myBranch
git checkout myBranch

Both the techniques are really long and cumbersome. But get the job done.

Samuel Rowe
  • 152
  • 1
  • 8