CODEWITHSUNDEEP
gitgit-merge
Matthew Scharley
Matthew Scharley

Reputation: 132254

Can someone explain this interesting git merging behaviour

I have two branches, 

A-C (master)
 \
  B-D (clean)

In A..C I added a directory with a bunch of files. In A..B I added the exact same directory and files, such that git diff C..B shows no changes in this directory. In B..D I did changes on those files. I want to merge those changes into master. I tried two different approaches, one worked cleanly and the other broke insanely badly:

git merge clean

The above command creates a tonne of conflicts, conflicts on every file in fact.

git merge clean^
git merge clean

The above works perfectly, merges recursively, no conflicts at all.

How and why does the above happen? Can git not look at the history and determine that it was an early split? Or would that be too potentially taxing to be used as a merge strategy?

Upvotes: 4

Views: 378

Answers (1)

Emil Sit
Emil Sit

Reputation: 23542

In the first case, git merge clean, Git has no common ancestor for the conflicting files upon which to base the merges, so it looks like you are trying to bring together two trees that have both created the same filenames but with different content. (The common ancestor A does not have any of the files that are conflicting.)

In the second case, git merge clean^ && git merge clean, the first merge again sees no common ancestors, but is able to trivially resolve it, because the files are the same. The second merge then can take the now-known ancestry, and just apply the diff.

Upvotes: 3

Related Questions