threads / discuss / 37309

possibly a spurious conflict in a three way merge

Subject: possibly a spurious conflict in a three way merge

## tl;dr

2 messages between Aug 7, 2014 and Aug 7, 2014.

replies: 1people: 2as markdown or json

meanlogin@gmail.com· Aug 7, 2014, 16:30 UTC · lore
git 2.0.4 on ubuntu 14.04 64
1. new repo
2. commit test.txt to master:
line1
line1
3. branch and checkout branch1
4. make and commit the following change to branch1:
#line1
#line2
5. checkout master
6. make and commit the following change to master:
line1
#line2
7. merge branch1, git sees a conflict:
<<<<<<< HEAD
line1
=======
#line1
 >>>>>>> branch1
#line2

Why? The first line changed in branch1 but not in master so a 3 way merge should take branch1 changes. Beyond Compare ( used as a mergetool) does not flag any conflicts.

Jonathan Nieder· Aug 7, 2014, 18:52 UTC · re: meanlogin@gmail.com · lore

Re: possibly a spurious conflict in a three way merge

Hi,
meanlogin@gmail.com wrote:
Show 23 quoted lines
> 2. commit test.txt to master:
> line1
> line1
>
> 3. branch and checkout branch1
> 4. make and commit the following change to branch1:
> #line1
> #line2
>
> 5. checkout master
> 6. make and commit the following change to master:
> line1
> #line2
>
> 7. merge branch1, git sees a conflict:
> <<<<<<< HEAD
> line1
> =======
> #line1
> >>>>>>> branch1
> #line2
>
> Why?
Thanks for a clear example.  On branch1 you made the following change:
 (a) modify lines 1 and 2
On master, you made a different change:
 (b) just modify line 2

The changes touch the same chunk of lines and don't produce the same result there. Git is being conservative and letting you know that the two branches didn't agree about what line 1 should say.

On the other hand, if you had a larger files and on branch1 made the following change:

 (a) modify lines 1 and 101
and on master, you made a different change:
 (b) just modify line 101

then the changes are touching different parts of the code and are merged independently. The result would be a clean merge where lines 1 and 101 are both modified.

Git's conservatism can be helpful when working with code, where adjacent lines are likely to be affecting a single behavior and the conflict can help the operator to know to be extra careful. It makes less sense for line-oriented input where every line is independent.

If you are often making changes to a line-oriented file, it may make sense to set up a custom merge driver to override git's merge behavior for that file. See 'Defining a custom merge driver' in gitattributes(5) for details about how that works.

Hope that helps, Jonathan

← back to recent threads