2 conflicts referencing the same path?

2 conflicts referencing the same path?

[Bryan Turner]

While investigating an issue with rendering conflicts on a pull
request, I noticed that the merge was producing this output (sanitized
for paths)

$ git merge --no-ff --log -m "Test" 190a25b6e0f32c7b8ccddf8c31e054149dece8b7
CONFLICT (rename/add): Rename A->B in HEAD. B added in
190a25b6e0f32c7b8ccddf8c31e054149dece8b7
Adding as B~190a25b6e0f32c7b8ccddf8c31e054149dece8b7 instead
...
Auto-merging B
CONFLICT (content): Merge conflicts in B

(There are several other conflicts listed "between" the two I'm
showing here, various rename/add, add/add and content conflicts, but
I'm trimming those out to focus on the lines that I think are relevant
to my question.)

This merge produces 2 (or is it 3?) conflicts for the same B path:
- Rename A to B in HEAD, add B in 190a25b
- Content conflicts in B

The version of B left in place _does_ contain conflict markers, after
the merge processes completes. The version added as B~190a25b has no
conflict markers; it just shows a small number of inserted lines.

The merge in question produces 23 different CONFLICT lines, but aside
from "composite" conflicts (rename/add, add/add) that can include the
same path multiple times in their output, only this one path is
mentioned in multiple CONFLICT lines.

I'm still trying to produce a set of steps that will allow a minimal
reproduction, but I thought I'd post to the list just to see if anyone
had any thoughts on how it could happen. Is it a "normal" (albeit
rare) case? Or could it represent some sort of issue in Git's 3-way
merge algorithm (in its behavior or perhaps in how the merge conflicts
are logged)?

Any insights appreciated!
Bryan Turner

Re: 2 conflicts referencing the same path?

[Elijah Newren]

Hi,

On Thu, Feb 1, 2018 at 3:00 PM, Bryan Turner <bturner@atlassian.com> wrote:
> While investigating an issue with rendering conflicts on a pull
> request, I noticed that the merge was producing this output (sanitized
> for paths)
>
> $ git merge --no-ff --log -m "Test" 190a25b6e0f32c7b8ccddf8c31e054149dece8b7
> CONFLICT (rename/add): Rename A->B in HEAD. B added in
> 190a25b6e0f32c7b8ccddf8c31e054149dece8b7
> Adding as B~190a25b6e0f32c7b8ccddf8c31e054149dece8b7 instead
> ...
> Auto-merging B
> CONFLICT (content): Merge conflicts in B
>
> (There are several other conflicts listed "between" the two I'm
> showing here, various rename/add, add/add and content conflicts, but
> I'm trimming those out to focus on the lines that I think are relevant
> to my question.)
>
> This merge produces 2 (or is it 3?) conflicts for the same B path:
> - Rename A to B in HEAD, add B in 190a25b
> - Content conflicts in B

Right, so the merge-base has just one (relevant) file, A.  For sake of
argument, let's say it's contents is "hello\nworld".

One side of history, leading to HEAD, also has one (relevant) file,
which was a rename of A->B which also changed its contents to say
"hello\nbeautiful\nworld"

The other side of history, leading to commit 190a25 has two files.
The original A, whose contents has changed to say
"hello\namazing\nworld", and a new file called B.

When you merge the two, the "hello world" file has been modified
differently on the two sides as well as having been renamed from A->B,
AND there was a separate file also placed at B on the other side of
history which gets in the way.  Git resolves the
two-files-getting-in-the-way-of-each-other (the rename/add) by moving
one of the two out of the way (though it really ought to move both out
of the way, but that's a tangent).  And it resolves the conflicting
content changes in the other B by doing a content merge with conflict
markers, giving a file with contents of the form:

"""
hello
<<<<<<
beautiful
======
amazing
>>>>>>
world
"""

and it treats that B (from the "rename") as more important than other
(the "add") which it shows by recording it at B.

> I'm still trying to produce a set of steps that will allow a minimal
> reproduction, but I thought I'd post to the list just to see if anyone
> had any thoughts on how it could happen. Is it a "normal" (albeit
> rare) case? Or could it represent some sort of issue in Git's 3-way
> merge algorithm (in its behavior or perhaps in how the merge conflicts
> are logged)?

It is "normal" to get this, and functioning as intended, albeit fairly
rare.  rename/rename(1to2) and rename/rename(2to1) conflicts could
provide very similar situations.

rename/add conflicts have three issues I know about[1], but that
didn't include the output messages being suboptimal.  That might just
mean my mind has been warped by reading merge-recursive.c or that I'm
too familiar with it, so I don't notice how much it could be improved.
If you can think of how to improve the messages, I'm happy to listen,
especially since I'm trying to find time to continue my rewrite of
merge-recursive.  It'd have to apply to other rename cases, as noted
above (and, in particular, each side of a rename/rename(1to2) can
further be involved in other collisions, such as rename/add or
rename/rename(2to1), so it could get hairy quick if the solution isn't
simple enough.)

[1] https://public-inbox.org/git/20171120221944.15431-6-newren@gmail.com/;
that patch and the others in the series are waiting for the directory
rename detection series to progress before I resubmit.

Elijah