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?

  • git: solving conflicts caused by rebase
  • What happens when Dan change text into 'aB' and John to 'abc'?
  • Django South migration conflict while working in a team
  • git rebase -i -autosquash conflict
  • Git in Visual Studio. Conflict prevents checkout
  • Git merge - trivial merge?
  • How to automatically download the same 8 repos for every from another 4 repos in a git?
  • Print branch description
  • Is there a git personal server for sharing changes between machines?
  • Why doesn't git merge-base report last merge point?
  • Using git merge, how can I merge a bugfix into multiple long-term branches?
  • Storing Rails assets in git? Alternatives?
  • 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.