Git merge didn't merge two files only?

I have master branch, and a release branch. Last commit on the release branch added couple lines to files, let’s say, A and B. Then these changes were merged into master (things happen).

Later, number of other commits were made to master, one of which removed those couple lines from A and B again.

Now I merge master into release. Everything merges fine (except for couple minor conflicts), but files A and B left unchanged with those several lines present.

How could this happen? I can checkout the commit on release branch before the merge and repeat it again with the same result. Any commands/switches to understand what’s happening during the merge?

It seems I’m just doing something wrong, but I don’t understand how to do it properly. I can replicate the issue very easily, and it seems it’s happening because the ‘bad’ line was first added on master, then removed, and them master merged into release, where ‘bad’ line was also present. So the two commits from master ‘annihilated’, and release left unchanged, right?

So, what I’m doing:
7aee9be is release with ‘bad’ line
84d7ed2 is master before all the changes, older than above

Now I checkout 84d7ed2, add ‘bad’ line, commit (on a new test branch).
Then I remove ‘bad’ line, commit.
So test branch doesn’t have the ‘bad’ line anymore.
Then I checkout 7aee9be and merge test branch into it. ‘bad’ line is back, and the merge commit doesn’t have any changes at all.

  • How to exclude files from merging?
  • Git: merge hides certain changes
  • Git - Merging two commits which are not in serial sequence - Commits pushed to remote repo already
  • Git Merge two repositories that are years apart with thousands of conflicts
  • Merge folder from one branch into another with git
  • How to merge/pull from remote repository
  • Git merge updates to a past branch
  • Git command error
  • 2 Solutions collect form web for “Git merge didn't merge two files only?”

    It is all about the common ancestor (in a 3-way merging):

    If, when doing the final merge (of test, with no bad line) to release (with bad line), the “bad line” was introduced in release after the common ancestor, then the merge would not remove it.

    Since that common ancestor:

    • release has introduced the bad line
    • test has introduced and then removed the bad line

    Merging test in release won’t remove the bad line in release in that case: compared to the common ancestor, test introduces no changes, while release does. The changes from release are preserved.

    I would start with git bisect to find out where did the problem started. Once you have the “bad” commit check it out and start track from that point to find out what went wrong. (since something did go wrong in your case)

    There are several options:

    1. Someone did a rebase so your commits are overwritten (not likely but its still an option, since if someone has done rebase most likely that you would have known about it. your branch could become unusable)
    2. Someone has pushed the “old” code with the force flag git push origin master --force which will result in overwriting the old code
    3. When you pulled (pull = fetch+merge) you had a conflict and you resolved it by leaving the lines in place so now they will be checked in again.

    As i suggested try to figure out when it all started with the help of git bisect. Once you figure out what went wrong it will be much easier to resolve it.

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