Git added diff interface text to versioned file

Question

I have had Git add what appears to be the interface output of the diff command to the lines of a file:

$ git pull
U       public_html/spider/spider.php
Pull is not possible because you have unmerged files.
Please, fix them up in the work tree, and then use 'git add/rm <file>'
as appropriate to mark resolution, or use 'git commit -a'.

$ git status
# On branch master
# Your branch and 'origin/master' have diverged,
# and have 2 and 1 different commit each, respectively.
#
# Unmerged paths:
#   (use "git add/rm <file>..." as appropriate to mark resolution)
#
#       both modified:      spider.php
#
no changes added to commit (use "git add" and/or "git commit -a")

$ git diff spider.php
diff --cc public_html/spider/spider.php
index a89b8ef,4b091a7..0000000
--- a/public_html/spider/spider.php
+++ b/public_html/spider/spider.php
@@@ -136,13 -136,7 +136,17 @@@ if ( isset($_SERVER['HTTP_USER_AGENT']
                                $providersList[] = $p['name'];
                        }
                }
++<<<<<<< HEAD
+
+              if ( ensure_fields($input, 'version') ) {
+                      $output['providers'] = $providers;
+              } else {
+                      $output['providers'] = $providersList;
+              }
+
++=======
+               $output['providers'] = $providersList;
++>>>>>>> 5de401379b275bdb805298fd3db919028506cc60
                $logData['providers'] = implode(', ', $providersList);

                echo json_encode($output);

$ git add spider.php

$ git status
# On branch master
# Your branch and 'origin/master' have diverged,
# and have 2 and 1 different commit each, respectively.
#
# Changes to be committed:
#
#       modified:   spider.php
#

Now, when I open the spider.php file, I find this, copied directly from VIM:

- bruno:spider$ vim spider.php
135             if ( $p['url']!='' ) {
136                 $providersList[] = $p['name'];
137             }
138         }
139 <<<<<<< HEAD
140 
141         if ( ensure_fields($input, 'version') ) {
142             $output['providers'] = $providers;
143         } else {
144             $output['providers'] = $providersList;
145         }
146 
147 =======
148         $output['providers'] = $providersList;
149 >>>>>>> 5de401379b275bdb805298fd3db919028506cc60
150         $logData['providers'] = implode(', ', $providersList);
151 
152         echo json_encode($output);

The only machine to edit files was this (local) machine. The only unusual Git usage preceding this situation was in an commit --amend after a push. Might that have caused this situation? If not, then what? Is this a Git bug, as it does appear to be?

Answer 1

part a) why did a merge happen?

this is not 100% definite, but probably:

you had:

A--B--C--D

you pushed this and then amended D to get:

A--B--C--D'

then at some point you pulled and got back commit D, that you pushed earlier and that has no formal relationship to D' that you created later. at this point a merge is necessary to create a commit that is a successor to both D and D'. that is where things got wrong.

as stated, i cannot be totally sure that it unfolded like this, but what you have there is for sure a merge that went wrong.

part b) how do merges happen and how are conflicts resolved?

git tries to do merges automatically and if both commits D and D' change different files or different parts of one file, the files are changed automatically and you simply have to do git commit to confirm. if D and D' both change the same part of one file (and do not change it in the exact same way), you have a merge conflict and git asks you to resolve it. thus it places the conflict markers in the file and they look just like this:

139 <<<<<<< HEAD
140 
141         if ( ensure_fields($input, 'version') ) {
142             $output['providers'] = $providers;
143         } else {
144             $output['providers'] = $providersList;
145         }
146 
147 =======
148         $output['providers'] = $providersList;
149 >>>>>>> 5de401379b275bdb805298fd3db919028506cc60

conflict markers tell you that there are two versions of this sections, one from <<<< to ==== and one from ==== to >>>>. HEAD and the hash are used to identify the respective versions with a commit. you are responsible to bring the file to its resolved version, by choosing either version or by keeping both versions (one after the other, in the right order) or by creating a totally new version (that hopefully has the effect of both versions combined). you can do that using the text editor of your choice or you can use tools like git mergetool. when you are happy with the result, you do git commit to confirm the merge.

what you (probably) did was "do nothing and commit" thus telling git the file is merged alright even though you did nothing about the conflict markers git placed within when you pulled.