Git conflicts generated by cherry-picks

Question

To start, I am new to git, but have been eating up documentation and similar issues on the topic like this and this (I will be referring to this latter question later in the post).

Summary: I was cherry-picking a commit from one branch to another, and after making a commit on one branch and then trying to merge them back together, I was receiving conflicts. See my answer below for what I think was going on.

Scenario: I have two files, one on a "master" branch, and one on a "secondary" branch. The "secondary" branch contains some files we don't want in master, and is only used by a few people, but most of the files we have in both "master" and in "secondary" should be consistent (everything in master is in secondary, but everything in secondary is not in master). To accomplish this, I have been commiting changes made in "master", using git checkout secondary to checkout my "secondary" branch, and then running git merge master. Unfortunately, I raised a conflict once, and now my brain is churning away trying to figure out what the conflict is.

Attempted Solution: At first, I thought it was because I had modified the files in both "secondary" and in "master", which I had. To solve this, I used git cherry-pick [commit] to pull the changes I had made in the secondary branch into the master branch. However, I still could not merge my master branch into the secondary branch. Git suggested using git add/rm (presumably git add or git rm, though that took me a bit to figure out) to mark which ones I wanted. So I deleted the version in the index and working tree in "secondary" using the git rm command. After this, I went back to to my "master" branch, recommitted the files I wanted merged into "secondary", went BACK into "secondary", and then ran git merge master again. To my chagrin, conflicts.

Question: Frankly, I think I have no idea what's going on. I thought that git merge master (when run on the secondary branch) would take all changes made in the git master commit and put those changes in the secondary branch. If that is what's happening, I don't understand the issue. I have deleted the files from secondary, and have committed my changes in master. Why can't I merge? The solution to the latter question I referred to earlier suggests it might be because the common ancestor contains something else, but I thought that the git cherry-pick [commit] would have taken care of that. Is the problem that a cherry-pick does not create a new merge base, and so even though the files in question were the same after the cherry-pick, they might still be different from their merge-base?

I apologize for the length of this question, I am trying super hard to understand, and feel like I'm running in circles. Any advice would be great.

Edit: I guess I'm also confused because I don't understand why git won't let me change branches to try and resolve this problem. When I try git checkout secondary now to try and maybe cherry-pick the commit changes into secondary, I get error: you need to resolve your current index first. I assume there must be a reason git wouldn't allow this behavior, I'm just not sure I see what it is.

Answer 1

Found the solution! What's happening is that the cherry-pick does not create a new merge-base (so they both share a common ancestor, but it was different than both of their current states). Therefore, when I modified master after the cherry-pick, all three of my files were different. To visualize:

Common Ancestor: File.txt: this is the common ancestor.

Then I make changes on secondary branch, and commit them.

Secondary: File.txt: now I've modified this file to be this!

Then I git checkout master and git cherry-pick [commit made on secondary].

Master: File.txt: now I've modified this file to be this!

However, the common ancestor is still File.txt: this is the common ancestor. If I make a commit on master, changing it to File.txt: now this is the new master!, I would have three different versions of File.txt! Thus, when I tried to merge, git complained about conflicts because it wasn't sure how to combine the two different files. To solve this, simply run git merge secondary directly after the cherry-pick while on master! So if we do this merge now, we get:

Common Ancestor: File.txt: now I've modified this file to be this!

It seems non intuitive because the merge between master and secondary doesn't actually do anything to their files, since they are identical at this point. However, it is necessary to do this merge to create a common ancestor before we make anymore changes to either branch. Hope this helps someone!

Answer 2

The last point first - your repo is in a limbo state. You can edit the conflict manually and complete the merge commit or you can back out of it

I think one or more commits on master you include the files that exist only on master. Git cannot merge those commits as they contain changes for files that don't exist.

Try 'git status' to see where you are currently; look for 'both modified' files. then 'git rm' to take files out of the merge or you can resolve the issues (conflicts) inside the files and add them back to the commit with 'git add'. Then 'git commit' to finish the merge.