Why does git sometimes mark added lines as changed lines (i.e. an empty conflict over an added piece of code)

I still don’t have a confirmed way to reproduce this but in case this is some well known issue, I’ll ask it anyway. What happens is that git often creates conflicts like this:

<<<<<<< HEAD
  } // action_do_add
=======
  } // action_do_add
...lots of code here...
>>>>>>> some_branch

So instead of noticing that I simply added a new piece of code, git thinks that I modified the whole line instead. This sometimes happens in the middle of the file but most often – in the end of the file. My guess is that it might have something to do with end-of-line characters but I yet have to run tests to confirm that. Has anyone had the same issue and if yes, how do you fix it?

  • Safe master-master setup with git? (writable git mirror)
  • What are the differences between GIT and SVN when it comes to merge conflicts solving
  • Force Git to always choose the newer version during a merge?
  • Where's the 3-way Git merge driver for .PO (gettext) files?
  • Better, simpler example of 'semantic conflict'?
  • git: solving conflicts caused by rebase
  • List files with git ls-files from root instead of current working directory
  • git remove file from repository but leave it on file system
  • How to run pip3+git from behind proxy with docker?
  • git-svn: is there a way to get it to play nice with submodules, or ignore them?
  • How do I close a GitHub issue without making a commit?
  • ruby markdown parser with WikiWord support?
  • One Solution collect form web for “Why does git sometimes mark added lines as changed lines (i.e. an empty conflict over an added piece of code)”

    When merging, git checks differences in context to the surrounding lines. Consider this code:

    def a
      do_something_a
    end
    
    def b
      do_something_b
    end
    
    def c
      do_something_c
    end
    

    When one branch changes something in method a (or deletes it), and another branch changes something in method c (or deletes it), you still have the context of method b for both diffs. That’s why the changes will probably merge without conflicts.

    However, if you have something like this:

    def a
      do_something_a
    end
    
    def c
      do_something_c
    end
    

    you will most likely end up with conflicts when editing one method in one branch and the other in another branch because you broke the corresponding context of the diff in the other branch.

    That’s also why it happens more often at the end of the file—because there is just the context above the diff, but none below it.

    Git Baby is a git and github fan, let's start git clone.