1

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?

EDIT. 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.

pronvit
  • 4,169
  • 1
  • 18
  • 27
  • A git diff similar to http://stackoverflow.com/a/28512602/6309 would be helpful to understand why that hunk is still there. – VonC Feb 15 '15 at 19:48
  • @VonC I updated the question with more details. – pronvit Feb 16 '15 at 12:39
  • 1
    What do you mean by "add 'bad' line, commit"? Do you merge the release branch into the test branch? Or do you make the same commit as on the release branch? If you do the latter than that's your problem. – Sascha Wolf Feb 16 '15 at 12:50
  • 1
    Maybe a graph of your commit history and the commits you do would help us understanding what you mean. – Sascha Wolf Feb 16 '15 at 12:52
  • 1
    `git log --graph --decorate --oneline $beforeitstarted..$attheproblem` is a very useful overview. – jthill Feb 16 '15 at 13:36

2 Answers2

1

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.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • I'm merging with the same revision of `release` that introduced the bad line. – pronvit Feb 16 '15 at 20:34
  • @mifki it doesn't matter: test didn't add any modification since bad lines were added then removed in test. – VonC Feb 16 '15 at 20:40
  • Got it. Any way to detect such cases (apart from not doing such things again)? I just want `release` to get the latest _content_, regardless of the history of that content. – pronvit Feb 16 '15 at 20:48
  • @mifki sure: http://stackoverflow.com/a/2862938/6309 (I prefer it to the "reset" or the "rename" branch solutions) – VonC Feb 16 '15 at 20:50
-1

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.

CodeWizard
  • 128,036
  • 21
  • 144
  • 167