[QUESTION] Git fails to detect merge conflict?

[Anton Ermolenko <aermolenko@atlassian.com>]

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.