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?

  • github api to compare commits, response status is diverged
  • git cherry-pick and merge by ignoring EOL changes
  • Is it possible to always (force) overwrite local changes when updating from SVN? Ignore conflicts?
  • Is git's merge conflict resolution more efficient than other SCMs and merge tools?
  • How to manage a code merges on git with multiple users?
  • git submodule merge conflict: how to visualize?
  • Why do excluded files keep reappearing in my git sparse checkout?
  • What exactly mean “:” when using git show?
  • Should “git gc” be run periodically on gerrit managed git repositories?
  • Git command to show which specific files are ignored by .gitignore
  • Find which commit is currently checked out in Git
  • git merge does not produce conflict on code deletion
  • 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.