4

Let's say we have a "master" branch with say 1000 of commits over 2 years. We have a long-lived feature branch "feature1", about 2 months old (branched from master at that time), with 100 commits. We continue work on both master and feature1 and occasionally merge master into feature1 (about 5 commits, every 2 days) to keep it from drifting too far. Every time we do this, a particular merge conflict keeps happening, the same one each time (and I resolve it manually). For completeness, in this example it's a JavaScript project.

My question: Why does git not "remember" how I resolved this conflict the first time and use the same resolution for the subsequent merges?

Optional wrinkle which may assist with answer:

My intuition is that if I create a new branch from master and then merge feature1 into the result (let's call it "master+feature1"), the same merge conflict will stop occurring with subsequent merges from master to master+feature1. In practice I believe I have seen this, although I do not have evidence. Proof or explanation would be interesting, and I believe it could help explain the answer to my main question.

I am not interested in rebasing for this question. (Assume feature1 is pushed to a shared remote and rebasing is undesirable.)

Will
  • 6,601
  • 3
  • 31
  • 42

1 Answers1

3

Git can and will remember previous resolutions if you enable "rerere".

Without a lot more specifics I can't say why your merge of master into feature1 keeps hitting the same conflict. I can only describe the general method by which a merge works: it finds the "merge base" (most recent common ancestor) of the thing you're merging-in (master) and the branch you're on (feature1), then finds (git diff) changes made since that common ancestor on each of these two branches. If only one "side" has changed something, there should be no conflict there, so "both sides" must be making changes that—at least in terms of running git diff—collide with each other.

If you're currently on branch feature11 and want to see what has changed in master since your most recent common ancestor:

git diff feature1...master   # three dots

To see what's changed in feature1 itself since then, reverse the names:

git diff master...feature1   # still 3 "."s

The three-dot form instructs git diff to use git merge-base to find the merge base. The diff is then done against the name on the right hand side.

1Actually, you don't have to be on the branch at all. If you are on the branch you can use the HEAD shortcut: git diff ...master and git diff master....

sonnyb
  • 3,194
  • 2
  • 32
  • 42
torek
  • 448,244
  • 59
  • 642
  • 775