threads / discuss / 51415

[QUESTION] Git fails to detect merge conflict?

Subject: [QUESTION] Git fails to detect merge conflict?

## tl;dr

3 messages between Jul 1, 2019 and Jul 5, 2019.

replies: 2people: 2as markdown or json

Anton Ermolenko· Jul 1, 2019, 23:28 UTC · lore

Hello folks,

I'm writing on behalf of a customer and I wonder if you could help me to clarify if the following test case should be considered a bug or if it is expected behavior.

  # create repository
  git init
  # add initial content
  cat << EOF > example.txt

--- START ---
  LINE 1
  LINE 2
  LINE 3
---  END  ---

EOF
  # commit the changes
  git add example.txt && git commit -m "Initial Commit"

  # create a branch
  git checkout -b change-a
  # introduce a change
  cat << EOF > example.txt

--- START ---
  LINE 1
  LINE 2
  LINE 3
  LINE 4
  LINE 5
  LINE 6
  LINE 7
  LINE 8
  LINE 9
---  END  ---

EOF
  # commit the change
  git commit -am "change a"

  # return to master and create another branch
  git checkout master && git checkout -b change-b
  # introduce another change
  cat << EOF > example.txt

--- START ---
  LINE 1
  LINE B
  LINE 3
  LINE D
  LINE E
  LINE 3
---  END  ---

EOF
  git commit -am "change b"

At this point the "change-a" diff with master is:

diff --git a/example.txt b/example.txt
index 1cebaff..605f2b0 100644
--- a/example.txt
+++ b/example.txt
@@ -3,5 +3,11 @@
   LINE 1
   LINE 2
   LINE 3
+  LINE 4
+  LINE 5
+  LINE 6
+  LINE 7
+  LINE 8
+  LINE 9
 ---  END  ---

and "change-b" diff with master is:

diff --git a/example.txt b/example.txt
index 1cebaff..cf5c0b2 100644
--- a/example.txt
+++ b/example.txt
@@ -1,7 +1,10 @@

 --- START ---
   LINE 1
-  LINE 2
+  LINE B
+  LINE 3
+  LINE D
+  LINE E
   LINE 3
 ---  END  ---

If a user to merge branches with "no-fast-forward" strategy, git does not detect
a conflict:

  # merge change-a first
  git merge --no-ff -m "merge change-a" change-a
  # merge change-b now
  git merge --no-ff -m "merge change-b" change-b

And the resulting content of "example.txt" is:

--- START ---
  LINE 1
  LINE B
  LINE 3
  LINE D
  LINE E
  LINE 3
  LINE 4
  LINE 5
  LINE 6
  LINE 7
  LINE 8
  LINE 9
---  END  ---

My understanding is that recursive merge here won't consider that situation to
be a merge conflict as the changes have been introduced in different spots in
the file.

Am I correct or is this a bug?

Thank you,
Anton.

Jonathan Nieder· Jul 2, 2019, 00:15 UTC · re: Anton Ermolenko · lore

Re: [QUESTION] Git fails to detect merge conflict?

Anton Ermolenko wrote:

> My understanding is that recursive merge here won't consider that situation to
> be a merge conflict as the changes have been introduced in different spots in
> the file.

Yes, that seems right to me.

Do you have more details about the context? What do these files look like? Are there other cues that we could use to discover that the customer intended the changes to conflict?

Thanks, Jonathan

Anton Ermolenko· Jul 5, 2019, 00:45 UTC · re: Jonathan Nieder · lore

Re: [QUESTION] Git fails to detect merge conflict?

Hello!

Thanks for you answer.

The original content of the file:

--- START ---
  LINE 1
  LINE 2
  LINE 3
---  END  —

Branch “change-a” modifies it to become:

--- START ---
  LINE 1
  LINE 2
  LINE 3
  LINE 4
  LINE 5
  LINE 6
  LINE 7
  LINE 8
  LINE 9
---  END  —

While branch “change-b” modifies it to become:

--- START ---
  LINE 1
  LINE B
  LINE 3
  LINE D
  LINE E
  LINE 3
---  END  —

Now, on master I’m able to perform “—no-ff” merge with and git does not detect any conflict. The result is this:

--- START ---
  LINE 1
  LINE B
  LINE 3
  LINE D
  LINE E
  LINE 3
  LINE 4
  LINE 5
  LINE 6
  LINE 7
  LINE 8
  LINE 9
---  END  —

Which is both changes applied sequentially - first, the change from “change-b” as it happens to be earlier in the file, then change from “change-a”.

Thank you, Anton.

Show 16 quoted lines

> On 2 Jul 2019, at 10:15 am, Jonathan Nieder <jrnieder@gmail.com> wrote:
> 
> Anton Ermolenko wrote:
> 
>> My understanding is that recursive merge here won't consider that situation to
>> be a merge conflict as the changes have been introduced in different spots in
>> the file.
> 
> Yes, that seems right to me.
> 
> Do you have more details about the context?  What do these files look
> like?  Are there other cues that we could use to discover that the
> customer intended the changes to conflict?
> 
> Thanks,
> Jonathan