How to force a merge to succeed when there are conflicts?

Question

I'm trying to merge a pull request that has one conflict in one file (see below). The instructions for merging the pull request are provided by github are as follows. Its important to to perform this merge so the person submitting the pr gets credit for it.

# Step 1: From your project repository, check out a new branch and test the changes.
git checkout -b droark-master master
git pull https://github.com/droark/cryptopp.git master

# Step 2: Merge the changes and update on GitHub.
git checkout master
git merge --no-ff droark-master
git push origin master

I know how to fix the one line in the one conflicting file. What I don't know how to do is make Git perform the merge and stop complaining about broken index files.

How do I make Git perform the merge, ensure the person who provided the pull request gets credit for it, and stop breaking index files?

---

I tried to repair the merge with Git merge errors. One set of errors turns into another set of errors, ad infinitum. I also tried resetting the problem file according to Ignore files during merge with plans to copy/paste the one line needed, but the broken index persists.

This has turned into a complete waste of time, and I am no longer interested in trying to do it Git's way since it wastes so much time. Now I simply want Git to perform the merge and stop breaking index files.

---

Here is the output produced when merging using github's instructions:

$ git pull https://github.com/droark/cryptopp.git master
From https://github.com/droark/cryptopp
 * branch            master     -> FETCH_HEAD
Auto-merging validate.h
Auto-merging validat2.cpp
Auto-merging validat1.cpp
Auto-merging test.cpp
CONFLICT (content): Merge conflict in test.cpp
Auto-merging pubkey.h
Automatic merge failed; fix conflicts and then commit the result.

Solution 1

There's no way to merge without resolving conflicts. Otherwise, how would git know what to merge? You can, however, checkout the version from either branch you're merging using git checkout --ours <filepath> or git checkout --theirs <filepath>. Here's an example:

Suppose you're on the master branch merging in staging:

git checkout master
git merge staging

And git shows a bunch of conflicts:

...
CONFLICT: Readme.md
...

If you want to keep the version of Readme.md that's on master, then you would run:

git checkout --ours Readme.md

Note that since you're on master --ours refers to "this" branch, i.e. master.

Now, you can simply add it to the index to mark it as resolved:

git add Readme.md

This effectively ignores any changes to Readme.md on the staging branch.

You can repeat this process for each file you want to omit from the merge. When you're done, commit as you normally would:

git commit -m "whatever..."

In order to repeat it for all files with conflicts you can do

for f in $(git diff --name-only --diff-filter=U | cat); do
   echo "Resolve conflict in $f ..."
   git checkout --theirs $f
done

Solution 2

There's no way around resolving conflicts, that's how revision control works (if Alice says "a" and Bob says "b", how should Git know which one is correct unless you tell it?). All you can do is direct git to resolve them itself when merging in one of several possible ways, e.g.

git merge -s recursive -X theirs <branch>

^{(-s recursive is the default when there's only one <branch> so you can omit it here)}

Now that you already have a conflict in your tree, you either

• follow the manual resolution route
  • edit the file to your heart's content
  • git add it (add in Git doubles as marking a file resolved)
  • git commit to complete the merge; or
• restore the pre-merge state with git merge --abort and retry the merge with the above-mentioned auto-resolution options

Solution 3

Resolving a conflict is just like dealing with any other work in progress. All changes must be staged (git add) and then committed. Files which have successfully auto merged are already staged. Conflicted files are not.

Edit the conflicted files to your satisfaction, stage them (git add), and when that is all done, git commit.

In your case specifically...

• Edit test.cpp to fix the conflicts (they have <<<< markers)
• git add test.cpp
• Run your tests to make sure everything is ok.
• git commit

Solution 4

Push development into master

git push --force origin branchA:branchB

This will force a merge and then push

Solution 5

If you know the changes in the current working branch is what you want, you can simply add ours flag to a git merge.

git merge -s ours master

This effectively ignores all other branch changes and guarantees the merge output is that of the current working branch.

More info and strategies here : https://www.atlassian.com/git/tutorials/using-branches/merge-strategy

View more solutions

Comments

[Schwern]

What do you mean by "breaking index files"?

[jww]

@Schwern - after the merge fails, I can't do anything with the repo because of problems with the index files (whatever they are in Git). For example, git checkout master results in error: you need to resolve your current index first. I want Git to stop breaking them so I can get on with my task at hand.

[Schwern]

To roll back a merge conflict, see the answers to "How to undo a git merge with conflicts?".

[chharvey]

git-scm.com/docs/merge-strategies

[jww]

Thanks. I don't want to resolve the conflict. I have wasted far too much time on it. I now want the merge to succeed. It will literally take me 3 seconds to re-add what is need by hand.

[Schwern]

@jww The merge cannot succeed while there are conflicts. You could git add the conflicted files without editing them and git commit to finish the merge, but then you'd have to fix them in the very next commit by doing the same thing. Might as well fix them in the merge, it will take the same effort and you won't have a broken merge commit.

[ivan_pozdeev]

Warning: --ours/--theirs doesn't merge changes, it takes one version of the file verbatim, completely ignoring the other.

[Shujito]

that's destructive

[q9f]

Even worse, --ours/--theirs does nothing.

[Felipe]

@5chdn it definitely checks out versions from the specified branch, as described in ivan's comment

[aswzen]

its dangerous, but files were still tracked