0

I cloned a repo, build a firmware from that and 'git pull' from time to time to stay uptodate.

This time I got a merge conflict for a very huge file (json), which - as it turned out - is automatically created, when the firmware is built. So the conflicts are there - from point of view of git - but they don't matter. I simply want the version from the repo replacing the local one.

I tried git merge -s theirs but this strategy is not known by git merge. I removed the file physically to get a fresh copy....nope...git is smarter than me.

How can I do a 'forget that file and send me the copy you have' to the remote git?

LeGEC
  • 46,477
  • 5
  • 57
  • 104

3 Answers3

1

If for a single file or only some of the conflicting files, use git checkout --theirs -- path/to/file or git checkout --ours -- path/to/file (depending on which version you want).

If you basically want to throw away all changes of one branch and continue working with the files of the other, but still keep the history, see How do I 'overwrite', rather than 'merge', a branch on another branch in Git? (spoiler: there is no "theirs" strategy, only an "ours" strategy).

If you want to still merge all changes that can be merged, but in case of conflicts resolve those conflicts with the version of the other branch, use the "recursive" strategy (the default) with the "theirs" strategy option: git merge -X theirs branch_to_merge.

If you don't care about your local branch's history, simply switch to the other branch and delete your local branch.

knittl
  • 246,190
  • 53
  • 318
  • 364
  • Do I need a 'git commit' afterwards to do a 'git pull' at some time afterwards? –  Nov 21 '20 at 15:17
  • @mcc if you use the `-s ours` strategy to merge, you don't need to commit. If there are conflicts, you always have to commit the conflict resolution. – knittl Nov 21 '20 at 15:37
1

Assuming that you have only uncommitted changes,

git checkout .
git pull

The first line would replace your uncommitted changes with that of your local repo, and the second line would pull the remote changes.

If you had committed something already and want to get rid of those as well,

git reset --hard <the last common commit hash>
git pull

Here, the first line resets the state to the last commit before your commits discarding all changes since then, and the second line pulls the changes.

Dharman
  • 30,962
  • 25
  • 85
  • 135
Aswin Rajeev
  • 97
  • 1
  • 10
  • In case if you want to discard only a part of your local code, you can go with the answer suggested by @knittle. However, this could potentially lead to unstable code state. – Aswin Rajeev Nov 21 '20 at 14:29
0

Let's start at the beginning.

  1. You say git merge ... (or git pull ..., which implicitly does a git merge). You are told there's a conflict over myfile.json. And you happen to know that the desired version of myfile.json is the "remote" version, the version coming in from the branch you are merging into your current branch.

  2. Now say git checkout --theirs myfile.json. That is the "remote" version of the file ("theirs"). You have now overwritten the worktree (conflicted) version with the incoming "theirs" version.

  3. Next, say git add myfile.json. That removes the conflict status. You are saying, "the state of myfile.json as it is now in the worktree is the state I want".

  4. Finally, say git merge --continue. The merge will be completed (assuming there are no other conflicts) and you will be given the opportunity to edit the commit message for the merge commit.

matt
  • 515,959
  • 87
  • 875
  • 1,141