9719

How do I force an overwrite of local files on a git pull? My local repository contains a file of the same filename as on the server.

error: Untracked working tree file 'example.txt' would be overwritten by merge

12
  • 53
    anyone reading this who thinks they might lose files, I've been in this position and found Sublime Text's buffer has saved me - if I'm working on something, then accidentally delete everything by trying to solve a similar problem to this or by using an answer on this question and have had the files open in Sublime (which there's a good chance of) then the files will still be there is Sublime, either just there, or in the undo history
    – Toni Leigh
    Commented Jan 20, 2016 at 8:51
  • 341
    git reset --hard origin/branch_to_overwrite Commented Mar 22, 2016 at 8:37
  • 5
    basically, only do a pull from develop after the initial checkout -b. do your work, then push back in.
    – llama
    Commented Aug 22, 2018 at 9:09
  • 5
    Short answer: delete and re-create branch. 1. Delete branch: git branch <branch> -D 2. Reset to a commit before the conflict: git reset <commit> --hard 3. Re-create the branch: git branch <branch> 4. Set tracking to the server: git --set-upstream-to=origin/<branch> <branch> 5. Pull: git pull`
    – Nino Filiu
    Commented Sep 24, 2018 at 8:54
  • 6
    To change all CRLF to LF endings, (start clean) git config core.autocrlf false; git ls-files -z | xargs -0 rm; git checkout .
    – Chloe
    Commented Jan 17, 2019 at 2:46

54 Answers 54

13325

⚠ Warning:

Any uncommitted local change to tracked files will be lost, even if staged.

But any local file that's not tracked by Git will not be affected.


First, update all origin/<branch> refs to latest:

git fetch --all

Backup your current branch (e.g. master):

git branch backup-master

Jump to the latest commit on origin/master and checkout those files:

git reset --hard origin/master

Explanation:

git fetch downloads the latest from remote without trying to merge or rebase anything.

git reset resets the master branch to what you just fetched. The --hard option changes all the files in your working tree to match the files in origin/master.


Maintain current local commits

[*]: It's worth noting that it is possible to maintain current local commits by creating a branch from master before resetting:

git checkout master
git branch new-branch-to-save-current-commits
git fetch --all
git reset --hard origin/master

After this, all of the old commits will be kept in new-branch-to-save-current-commits.

Uncommitted changes

Uncommitted changes, even if staged (with git add), will be lost. Make sure to stash or commit anything you need. For example, run the following:

git stash

And later (after git reset), reapply these uncommitted changes:

git stash pop

Which may create merge conflicts.

36
  • 37
    Watch out! If you have local unpushed commits this will remove them from your branch! This solution keeps untracked files not in the repository intact, but overwrites everything else.
    – Matthijs P
    Commented May 17, 2012 at 8:18
  • 569
    It's a popular question, so I'd like to clarify on the top comment here. I just executed commands as described in this answer and it hasn't removed ALL the local files. Only the remotely tracked files were overwritten, and every local file that has been here was left untouched.
    – Red
    Commented Nov 22, 2012 at 10:38
  • 49
    in case you're pulling from a repo that has its remote branch name different from "master", use git reset --hard origin/branch-name Commented Dec 17, 2013 at 11:17
  • 257
    Given the amount of upvotes to this question and answer, I think that git should incorporate a command like git pull -f
    – Sophivorus
    Commented Aug 26, 2014 at 1:33
  • 24
    Commits that weren't pushes before the hard reset can be recovered using git reflog, which list all commits, also those without a base. Until you cleanup your local copy using git gc, then all is lost
    – Koen.
    Commented Feb 10, 2015 at 22:24
1433

This will remove all uncommitted changes, even if staged,
and then pull:

git reset --hard HEAD
git pull

But any local file that's not tracked by Git will not be affected.

17
  • 35
    I've done this and some local files that were no longer in repo were left on the disk. Commented Apr 8, 2011 at 16:00
  • 46
    I do not think that this is correct. the above will perform a merge, not overwrite which was requested in the question: "How to force git to overwrite them?" I do not have the answer, I am currently looking for it.. at the moment I switch to the branch with with the code that I want to keep "git checkout BranchWithCodeToKeep", then do "git branch -D BranchToOverwrite" and then finally "git checkout -b BranchToOverwrite". you will now have the exact code from BranchWithCodeToKeep on the branch BranchToOverwrite without having to perform a merge.
    – felbus
    Commented Jul 13, 2011 at 10:11
  • 318
    instead of merging using 'git pull', try git fetch --all followed by 'git reset --hard origin/master' Commented Feb 21, 2012 at 14:56
  • 11
    yep, the @lloydmoore solution worked for me. Could do with being an answer rather than just a comment. Commented Nov 19, 2012 at 9:54
  • 6
    This will reset the current changes back to the last branch commit pulled. Then git pull merges the changes from the latest branch. This did exactly what I wanted it to do.. Thanks!
    – Codeversed
    Commented Dec 5, 2014 at 17:42
607

WARNING: git clean deletes all your untracked files/directories and can't be undone.


Sometimes just clean -f does not help. In case you have untracked DIRECTORIES, -d option also needed:

# WARNING: this can't be undone!

git reset --hard HEAD
git clean -f -d
git pull

WARNING: git clean deletes all your untracked files/directories and can't be undone.

Consider using -n (--dry-run) flag first. This will show you what will be deleted without actually deleting anything:

git clean -n -f -d

Example output:

Would remove untracked-file-1.txt
Would remove untracked-file-2.txt
Would remove untracked/folder
...
10
  • 3
    You can give git clean a path argument to be more specific and avoid deleting untracked files that aren't conflicting.
    – joachim
    Commented Oct 18, 2011 at 10:08
  • 8
    I think the scenario description makes it clear that he doesn't really want to throw away the content. Rather what he wants is to stop git baulking at overwriting the files. @Lauri, this should not have happened to you. Unfortunately people seem to have misread the essence of scenario description - see my suggestion.
    – Hedgehog
    Commented Feb 11, 2012 at 23:05
  • 27
    FINALLY. git clean -f -d is handy when make clean fails to clean everything.
    – earthmeLon
    Commented Jun 23, 2012 at 4:32
  • 9
    @crizCraig unless they are added in .gitignore Commented Jun 13, 2013 at 6:58
  • 10
    @earthmeLon, for that you might want git clean -dfx. The -x ignores .gitignore. Typically your build products will be in .gitignore. Commented Aug 12, 2015 at 18:28
498

Like Hedgehog I think the answers are terrible. But though Hedgehog's answer might be better, I don't think it is as elegant as it could be. The way I found to do this is by using fetch and merge with a defined strategy. Which should make it so that your local changes are preserved as long as they are not one of the files that you are trying to force an overwrite with.

First do a commit of your changes

 git add *
 git commit -a -m "local file server commit message"

Then fetch the changes and overwrite if there is a conflict

 git fetch origin master
 git merge -s recursive -X theirs origin/master

-X is an option name, and theirs is the value for that option. You're choosing to use their changes (the other option is ours changes) if there is a conflict.

13
  • 77
    This is the best answer I've seen so far. I haven't tried it, but unlike other answers, this doesn't attempt to nuke all your untracked files, which is very dangerous for obvious reasons.
    – huyz
    Commented May 7, 2012 at 9:36
  • 9
    Ditto - this worked for me when doing a very large merge (GitHub pull request) where I just wanted to accept it all on top of what I had. Good answer! In my case the last two commands were: 1) get fetch other-repo; 2) git merge -s recursive -X theirs other-repo/master
    – quux00
    Commented Jul 27, 2012 at 1:44
  • 5
    This will overwrite any conflicts with the repositories files and not your local ones, correct?
    – Nathan F.
    Commented Dec 5, 2014 at 11:40
  • 7
    Best answer. The highest accepted answer left me in my case on detached head. I switched back to local master branch and ran git merge -X theirs origin/master
    – petergus
    Commented Mar 11, 2016 at 12:46
  • 12
    i just wanted freaking git to overwrite everything and shut up about it. after all im just using it between my work pc and some raspberry pi systems. Whishing for a force overwrite option, at least for project leader
    – clockw0rk
    Commented Jun 5, 2019 at 14:39
434

Instead of doing:

git fetch --all
git reset --hard origin/master

I'd advise doing the following:

git fetch origin master
git reset --hard origin/master

No need to fetch all remotes and branches if you're going to reset to the origin/master branch right?

9
  • 4
    Your answer is just what you needed for your rep. I must ask, does this also remove all untracked files? Commented Jan 7, 2014 at 6:38
  • 7
    Yeah, most of my rep is coming from here :) This will also remove all untracked files. Something I had forgotten and was painfully reminded of just 2 days ago...
    – Johanneke
    Commented Jan 9, 2014 at 12:01
  • 2
    See the comments on this other answer: stackoverflow.com/a/8888015/2151700
    – Johanneke
    Commented Jan 9, 2014 at 12:02
  • This did not remove my untracked files; which is actually what I'd expect. Is there a reason it might for some people and not for others? Commented Apr 19, 2016 at 15:27
  • 2
    This is exactly what I needed: something that overwrites untracked files that exist in the remote, and leaves everything else intact.
    – Ledazinha
    Commented Dec 20, 2017 at 22:37
162

It looks like the best way is to first do:

git clean

To delete all untracked files and then continue with the usual git pull...

14
  • 5
    I tried using "git clean" to solve the same issue, but it did not resolve it. git status says "Your branch and 'origin/master' have diverged, # and have 2 and 9 different commit(s) each, respectively." and git pull says something similar to what you have above.
    – slacy
    Commented Sep 24, 2009 at 4:25
  • 51
    git clean is a rather blunt instrument, and could throw away a lot of things that you may want to keep. Better to remove or rename the files that git is complaining about until the pull succeeds. Commented Jul 2, 2010 at 13:21
  • 3
    I do not think this works in general. Isn't there a way to do basically a git clone remote via a forced git pull?
    – safetyduck
    Commented Nov 29, 2010 at 18:30
  • 21
    @mathick: git fetch origin && git reset --hard origin/master Commented Feb 23, 2011 at 4:24
  • 4
    Is git clean the best answer here? Seems like removing files isn't necessarily what the OP wants. They asked for 'an overwrite of local files' not deletion.
    – JohnAllen
    Commented Mar 4, 2014 at 8:28
137

Warning, doing this will permanently delete your files if you have any directory/* entries in your gitignore file.

Some answers seem to be terrible. Terrible in the sense of what happened to @Lauri by following David Avsajanishvili suggestion.

Rather (git > v1.7.6):

git stash --include-untracked
git pull

Later you can clean the stash history.

Manually, one-by-one:

$ git stash list
stash@{0}: WIP on <branch>: ...
stash@{1}: WIP on <branch>: ...

$ git stash drop stash@{0}
$ git stash drop stash@{1}

Brutally, all-at-once:

$ git stash clear

Of course if you want to go back to what you stashed:

$ git stash list
...
$ git stash apply stash@{5}
8
  • 3
    No I don't think so. Stashing just moves uncommitted files out of the way. The above also moves (stashes) files that git does not track. This prevents files that have been added to the remote, which have not yet pulled down to your machine - but which you have created (!) - to be pulled down. All without destroying the uncommitted work. Hope that makes sense?
    – Hedgehog
    Commented Mar 20, 2012 at 23:54
  • 4
    If you don't have 1.7.6, you can mimic --include-untracked simply by temporarily git add-ing your entire repo, then immediately stashing it.
    – nategood
    Commented May 1, 2012 at 22:48
  • 4
    I agree with Hedgehog. If you do the popular answers here, you are more than likely going to find you've inadvertently killed a lot of stuff that you didn't really want to lose.
    – AfroRick
    Commented Jan 31, 2013 at 21:28
  • 2
    I had other untracked files--besides the one the merge/pull wanted to overwrite, so this solution worked best. git stash apply brought back all my untracked files with the exception (rightly) of the ones that the merge had already created: "already exists, no checkout." Worked perfectly.
    – BigBlueHat
    Commented Apr 25, 2013 at 4:55
  • 3
    This is the cleanest answer, and should be the accepted one. To save some typing you can use the short form: git stash -u.
    – ccpizza
    Commented Mar 23, 2017 at 8:30
120

You might find this command helpful to throw away local changes:

git checkout <your-branch> -f

And then do a cleanup (removes untracked files from the working tree):

git clean -f

If you want to remove untracked directories in addition to untracked files:

git clean -fd
4
  • I think the scenario description makes it clear that he doesn't really want to throw away the content. Rather what he wants is to stop git baulking at overwriting the files. See my suggestion.
    – Hedgehog
    Commented Feb 11, 2012 at 23:03
  • 5
    Though that answer might not fit exactly the description, it still saved me from the frustration of git twiddling with the carriage returns (event with autocrlf false). When git reset --hard HEAD does not leave you with "no" modified files, these "-f" flags are quite helpful. Thanks a bunch.
    – Kellindil
    Commented Jan 16, 2013 at 10:28
  • "git clean -fd" saved me
    – Jzapata
    Commented Oct 12, 2022 at 19:13
  • doesn't work at all fatal: Need to specify how to reconcile divergent branches.
    – Gargo
    Commented Jun 10 at 9:05
108

Instead of merging with git pull, try this:

git fetch --all

followed by:

git reset --hard origin/master.

1
  • this wont work in scripts cause you have to know the branch name. Look at my solution for a generic way
    – warch
    Commented Nov 25, 2021 at 9:02
81

The only thing that worked for me was:

git reset --hard HEAD~5

This will take you back five commits and then with

git pull

I found that by looking up how to undo a Git merge.

2
  • This was what ultimately worked for me as I had force pushed my branch to the origin repo and kept getting merge conflicts when trying to pull it to my remote repo..
    – jwfrench
    Commented May 7, 2014 at 5:16
  • Hi, actually this is a trick for a work around but really effective. Because some conflicts may happen just in few commits then reverting 5 commits will make sure no conflicts with remote code.
    – Henry Le
    Commented Nov 21, 2014 at 10:03
71

The problem with all these solutions is that they are all either too complex or, an even bigger problem, is that they remove all untracked files from the webserver, which we don't want since there are always needed configuration files which are on the server and not in the Git repository.

Here is the cleanest solution which we are using:

# Fetch the newest code
git fetch

# Delete all files which are being added, so there
# are no conflicts with untracked files
for file in `git diff HEAD..origin/master --name-status | awk '/^A/ {print $2}'`
do
    rm -f -- "$file"
done

# Checkout all files which were locally modified
for file in `git diff --name-status | awk '/^[CDMRTUX]/ {print $2}'`
do
    git checkout -- "$file"
done

# Finally pull all the changes
# (you could merge as well e.g. 'merge origin/master')
git pull
  • The first command fetches the newest data.

  • The second command checks if there are any files that are being added to the repository and deletes those untracked files from the local repository which would cause conflicts.

  • The third command checks-out all the files which were locally modified.

  • Finally, we do a pull to update to the newest version, but this time without any conflicts, since untracked files which are in the repo don't exist anymore and all the locally modified files are already the same as in the repository.

3
  • Using "git merge origin/master" as the last line (like you say in your note) instead of "git pull" will be faster as you've already pulled down any changes from the git repo.
    – Josh
    Commented May 6, 2013 at 6:21
  • 2
    Yeah of course, git merge origin/master will be faster and probably even safer. Since if someone pushed new changes during the removal of of files of this script (which is not likely to happen, but possible), the whole pull could fail. The only reason I put pull in there is because someone might not be working on the master branch, but some other branch and I wanted the script to be universal. Commented Sep 1, 2013 at 22:25
  • If you have locally created files like option files, put them in .gitignore.
    – Sebi
    Commented Nov 21, 2017 at 11:41
69

First of all, try the standard way:

git reset HEAD --hard # To remove all not committed changes!
git clean -fd         # To remove all untracked (non-git) files and folders!

Warning: Above commands can results in data/files loss only if you don't have them committed! If you're not sure, make the backup first of your whole repository folder.

Then pull it again.

If above won't help and you don't care about your untracked files/directories (make the backup first just in case), try the following simple steps:

cd your_git_repo  # where 'your_git_repo' is your git repository folder
rm -rfv *         # WARNING: only run inside your git repository!
git pull          # pull the sources again

This will REMOVE all git files (excempt .git/ dir, where you have all commits) and pull it again.


Why git reset HEAD --hard could fail in some cases?

  1. Custom rules in .gitattributes file

    Having eol=lf rule in .gitattributes could cause git to modify some file changes by converting CRLF line-endings into LF in some text files.

    If that's the case, you've to commit these CRLF/LF changes (by reviewing them in git status), or try: git config core.autcrlf false to temporary ignore them.

  2. File system incompability

    When you're using file-system which doesn't support permission attributes. In example you have two repositories, one on Linux/Mac (ext3/hfs+) and another one on FAT32/NTFS based file-system.

    As you notice, there are two different kind of file systems, so the one which doesn't support Unix permissions basically can't reset file permissions on system which doesn't support that kind of permissions, so no matter how --hard you try, git always detect some "changes".

65

Bonus:

In speaking of pull/fetch/merge in the previous answers, I would like to share an interesting and productive trick,

git pull --rebase

This above command is the most useful command in my Git life which saved a lot of time.

Before pushing your newly commit to server, try this command and it will automatically synchronise the latest server changes (with a fetch + merge) and will place your commit at the top in the Git log. There isn't any need to worry about manual pull/merge.

Find details in What does "git pull --rebase" do?.

3
  • 8
    In short: git pull -r.
    – kenorb
    Commented Oct 15, 2019 at 9:29
  • In my case, before doing that, I had to 1) git add -A, 2) git commit -m 3) and finally git pull rebase. Thank you.
    – Pathros
    Commented Feb 3, 2021 at 20:10
  • this removes my committed changes. what am I doing wrong?
    – Nikhil S
    Commented Mar 2, 2023 at 19:20
60

I had the same problem. No one gave me this solution, but it worked for me.

I solved it by:

  1. Delete all the files. Leave just the .git directory.
  2. git reset --hard HEAD
  3. git pull
  4. git push

Now it works.

2
  • 2
    Same here. Sometimes only the very hard solution works, it happens often that only reset and clean are not enough somehow...
    – jdehaan
    Commented Dec 15, 2011 at 11:28
  • It is a bad solution to delete all files. What if your project is huge?
    – Gargo
    Commented Jun 10 at 9:06
53

Here is a generic solution if you do not always want to paste the branch name or you want to automate this within a script

git fetch
git reset --keep origin/$(git rev-parse --abbrev-ref HEAD)

If you want to reset your local changes too:

git fetch
git reset --hard origin/$(git rev-parse --abbrev-ref HEAD)

You also could add a bash alias using this command:

alias gplf='git fetch && echo "HEAD was at $(git rev-parse --short HEAD)" && git reset --hard origin/$(git rev-parse --abbrev-ref HEAD)'
3
  • 4
    If you find yourself using this frequently add a bash shortcut alias gplf='git fetch && echo "HEAD was at $(git rev-parse --short HEAD)" && git reset --hard origin/$(git rev-parse --abbrev-ref HEAD)'
    – Paul Odeon
    Commented Nov 13, 2019 at 9:43
  • 2
    Brilliant. Thanks! People do not consider automated scripts when answering. This is very elegant when you just can't pass the branch name along. Commented Sep 24, 2020 at 16:24
  • 3
    This middle one worked for me: git fetch followed by git reset --hard origin/$(git rev-parse --abbrev-ref HEAD). I chose it for its simplicity and the recentness of the answer.
    – Nike
    Commented Jul 18, 2022 at 19:33
40

I had a similar problem. I had to do this:

git reset --hard HEAD
git clean -f
git pull
1
  • 10
    use git clean with caution
    – nategood
    Commented Mar 30, 2012 at 16:39
38

I summarized other answers. You can execute git pull without errors:

git fetch --all
git reset --hard origin/master
git reset --hard HEAD
git clean -f -d
git pull

Warning: This script is very powerful, so you could lose your changes.

4
  • 3
    This will overwrite modified files (files that were previously checked in) and it will remove untracked files (files that have never been checked in). Exactly what I was looking for, thanks!
    – styfle
    Commented Mar 3, 2016 at 16:01
  • 4
    I suspect the third line git reset --hard HEAD may be redundant; my local man page (2.6.3) say that reset in the second line git reset --hard origin/master "defaults to HEAD in all forms." Commented Apr 19, 2016 at 15:40
  • 3
    @arichards I think your suspect is right but if second line will not work(by any reason) third line work well to reset. This solution doesn't need to be optimized. I just summarized other answers. That's all. Thank you for your comment. :) Commented Apr 20, 2016 at 2:12
  • Thanks for the summary. These steps are indeed powerful :)
    – Glorian
    Commented Dec 10, 2020 at 17:28
34
git fetch --all
git reset --hard origin/develop
4
  • 1
    git reset: This part of the command is used to reset the current branch to a specified commit or reference. Commented Oct 19, 2023 at 11:59
  • 2
    --hard: This option is used to specify the reset mode. In --hard mode, not only the branch pointer is moved to the specified commit or reference, but the working directory and the index (staging area) are also forcefully updated to match that commit. This means any changes in your working directory and staging area that are not part of the specified commit will be permanently removed. Commented Oct 19, 2023 at 11:59
  • 1
    origin/develop: This is the reference to which you want to reset your current branch. In this case, you are resetting your current branch to the state of the "develop" branch as it exists in the remote repository referred to as "origin." This is typically used when you want to discard all your local changes and synchronize your branch with the latest state of the "develop" branch on the remote repository. Commented Oct 19, 2023 at 12:00
  • Also a good idea if you pull stuff, you have permissions to .git directory but not to the source files and the pull fails due to permissions on changes to the filesystem, but for git it looks like a pull was successful
    – Jiří
    Commented May 17 at 13:55
31

Based on my own similar experiences, the solution offered by Strahinja Kustudic above is by far the best. As others have pointed out, simply doing hard reset will remove all the untracked files which could include lots of things that you don't want removed, such as config files. What is safer, is to remove only the files that are about to be added, and for that matter, you'd likely also want to checkout any locally-modified files that are about to be updated.

That in mind, I updated Kustudic's script to do just that. I also fixed a typo (a missing ' in the original).

#/bin/sh

# Fetch the newest code
git fetch

# Delete all files which are being added,
# so there are no conflicts with untracked files
for file in `git diff HEAD..origin/master --name-status | awk '/^A/ {print $2}'`
do
    echo "Deleting untracked file $file..."
    rm -vf "$file"
done

# Checkout all files which have been locally modified
for file in `git diff HEAD..origin/master --name-status | awk '/^M/ {print $2}'`
do
    echo "Checking out modified file $file..."
    git checkout $file
done

# Finally merge all the changes (you could use merge here as well)
git pull
2
  • Using "git merge origin/master" as the last line (like you say in your note) instead of "git pull" will be faster as you've already pulled down any changes from the git repo.
    – Josh
    Commented May 6, 2013 at 6:20
  • The checkout of modified files is needed, so this works 100% of times. I updated my script with that a long time ago, but forgot to update here as well. I also use it a little differently than you. I checkout files which have any type of modification, not just M, so it works all the time. Commented Sep 1, 2013 at 22:48
27

It seems like most answers here are focused on the master branch; however, there are times when I'm working on the same feature branch in two different places and I want a rebase in one to be reflected in the other without a lot of jumping through hoops.

Based on a combination of RNA's answer and torek's answer to a similar question, I've come up with this which works splendidly:

git fetch
git reset --hard @{u}

Run this from a branch and it'll only reset your local branch to the upstream version.

This can be nicely put into a git alias (git forcepull) as well:

git config alias.forcepull "!git fetch ; git reset --hard @{u}"

Or, in your .gitconfig file:

[alias]
  forcepull = "!git fetch ; git reset --hard @{u}"

Enjoy!

1
  • This answer is also nice because it works regardless of which branch you are on!
    – leafmeal
    Commented Sep 11, 2018 at 20:14
26

I believe there are two possible causes of conflict, which must be solved separately, and as far as I can tell none of the above answers deals with both:

  • Local files that are untracked need to be deleted, either manually (safer) or as suggested in other answers, by git clean -f -d

  • Local commits that are not on the remote branch need to be deleted as well. IMO the easiest way to achieve this is with: git reset --hard origin/master (replace 'master' by whatever branch you are working on, and run a git fetch origin first)

0
26

I had the same problem and for some reason, even a git clean -f -d would not do it. Here is why: For some reason, if your file is ignored by Git (via a .gitignore entry, I assume), it still bothers about overwriting this with a later pull, but a clean will not remove it, unless you add -x.

26

I am not sure why anyone did not talk about FETCH_HEAD yet.

git fetch origin master && git reset --hard FETCH_HEAD

If you want to put it in an alias, the command would be:

git config --global alias.fpull '!git fetch origin master && git reset --hard FETCH_HEAD'
3
  • Because SO does not trust someone to make a 1-char edit (?!?!?): & is not same as &&! Commented Jul 7, 2022 at 4:02
  • 2
    @ConnorClark I replaced & with &&. Commented Jul 7, 2022 at 4:29
  • 2
    Only this works
    – Tai Le
    Commented Mar 28, 2023 at 3:07
24

An easier way would be to:

git checkout --theirs /path/to/file.extension
git pull origin master

This will override your local file with the file on git

22

I have a strange situation that neither git clean or git reset works. I have to remove the conflicting file from git index by using the following script on every untracked file:

git rm [file]

Then I am able to pull just fine.

1
  • Thanks! I found that this is needed if you've made any special adjustments to ignore changes on file in the repo. i.e git update-index --assume-unchanged <file>
    – skupjoe
    Commented Jan 20, 2023 at 23:25
22

I know of a much easier and less painful method:

$ git branch -m [branch_to_force_pull] tmp
$ git fetch
$ git checkout [branch_to_force_pull]
$ git branch -D tmp

That's it!

2
  • I tried doing as suggested in this answer. NO FILES AT ALL were pulled down from the remote repository. Actually not very surprising when you think about it - after all there is no reference at all to origin/<branch_to_force_pull>. Commented Dec 10, 2020 at 11:58
  • Hmm this looks like what I need to try. I have 50+ files & untracked files in my working copy with my personal debug code. So every time I have merge conflicts on a handful of files, it is unwieldy to do any of the other methods (like reset, stash, etc.) mentioned in this thread. Commented Mar 8, 2023 at 18:58
20

I just solved this myself by:

git checkout -b tmp # "tmp" or pick a better name for your local changes branch
git add -A
git commit -m 'tmp'
git pull
git checkout master # Or whatever branch you were on originally
git pull
git diff tmp

where the last command gives a list of what your local changes were. Keep modifying the "tmp" branch until it is acceptable and then merge back onto master with:

git checkout master && git merge tmp

For next time, you can probably handle this in a cleaner way by looking up "git stash branch" though stash is likely to cause you trouble on the first few tries, so do first experiment on a non-critical project...

18

Just do

git fetch origin branchname
git checkout -f origin/branchname // This will overwrite ONLY new included files
git checkout branchname
git merge origin/branchname

So you avoid all unwanted side effects, like deleting files or directories you wanted to keep, etc.

1
  • Nice. By first using checkout -f into the branch I wanted to merge from, that got rid of all the problematic untracked files. Then I could checkout again my destination, and finally merge without issues. Commented Oct 2, 2020 at 17:06
17

Requirements:

  1. Track local changes so no-one here ever loses them.
  2. Make the local repository match the remote origin repository.

Solution:

  1. Stash the local changes.
  2. Fetch with a clean of files and directories ignoring .gitignore and hard reset to origin.

    git stash --include-untracked
    git fetch --all
    git clean -fdx
    git reset --hard origin/master
    
16

Reset the index and the head to origin/master, but do not reset the working tree:

git reset origin/master
1
  • I personally found this to be most useful. It then keeps your working tree so you can check it in again. For my issue, I had the same files deleted as being added so it was stuck. Weird, I know. Commented Jan 4, 2014 at 21:03

Not the answer you're looking for? Browse other questions tagged or ask your own question.