Git conflicts after resolving some-CodePudding

I have problem

I have trouble getting my pull request of long living branch to get merged into the master, because I have conflicts that aren't solved even if I try to solve them.

So I see that GitHub tells me that I have conflicts so I cannot merge my feature branch my-feature-branch into the master. I create a new branch solve-conflicts-branch from the my-freature-branch. I merge master into the solve-conflicts-branch. Now I have conflicts in the solve-conflicts-branch and I solve those by using "Theirs" and some of the conflicts using "Mine". I commit the changes and create PR to merge these changes to the my-feature-branch. So PR goes through and I merge.

What I expect to see is that the first PR gets updated and the conflicts are solved but this is not the case. The same conflicts that I resolved in the solve-conflicts-branch are still there.

CodePudding user response：

When you squash, you are tricking git (in a very nasty for you way) into thinking that the merge did not take place. Let me explain so you can see what the problem is when you squash. Suppose you have this:

*   Something on a branch (some-branch)
| * first tip of master (master)
|/
* second commit
* first commit

Suppose that you run a first merge. When you merge, git will, roughly, consider the differences introduced by both branches since their last common ancestor.... so, if you merged master into some-branch to pick up the latest from other developers, git would have to consider this tree, right?

*   Something on a branch (some-branch)
| * first tip of master (master)
|/
* second commit

When you finish the merge, you might get something like this (assume we solved some conflicts in the merge):

* Merging changes from master (some-branch)
|\
* | Something on a branch
| * first tip of master (master)
|/
* second commit
* first commit

That all looks beautiful to me.... now, time goes by a little bit and now we have this:

* A new commit in feature branch (some-branch)
| * A new commit in master (master)
* | Merging changes from master
|\|
* | Something on a branch
| * first tip of master
|/
* second commit
* first commit

If you tried to merge this time, again, git would have to look for the latest common ancestor and see what changed on each branch from there so, it would have to consider this (look at the last common ancestor):

* A new commit in feature branch (some-branch)
| * A new commit in master (master)
* | Merging changes from master
 \|
  * First tip of master

Now, if in the last commit of each branch there is no messing up with the code that was already conflicting in the first merge, you would not get a complain from git involving that piece of code as it would not be involved in changes coming from any of the two branches past first tip of master.

Now, consider what the first merge would look like after the first merge if you squash:

* Merging changes from master (some-branch)
*   Something on a branch
| * first tip of master (master)
|/
* second commit
* first commit

Now, let's add the 2 commits at the tip of each branch, like we did before:

* a new commit in feature branch (some-branch)
* Merging changes from master
*   Something on a branch
| * A new commit in master (master)
| * first tip of master
|/
* second commit
* first commit

If you tried merging now, what tree would git have to consider to merge? It would have to again consider changes coming since second commit, just like last time and, given that there were conflicts before, it's more than likely that the 2 branches will still conflict on the same sections of code because, to git, you have different changes coming from the 2 branches since second commit. So, yes, you solved conflicts before, but given that you did not really merge, git does not know about it when you are trying to merge this time.

I hope that helps explain why it happens.