Unexpected result from bzr merge: line missing?

Terry Jones terry at jon.es
Thu Jul 29 00:49:09 BST 2010


Hi Martin

> The areas that aren't in conflict aren't necessarily sections that are
> common between the two files, rather they're sections where bzr doesn't
> think there is any disagreement between the two changes.  The basic case of
> this (for 3 way merge) is that one side changed the text and the other
> didn't.

Another good clarification... I should be more careful.

> The case you have here is a good example where there really are
> overlapping changes and you need to not just choose one of the blocks but
> rather edit them together to get the right parts from each.

Yes. My mistake was in assuming that this was not one of those cases, I was
in "A versus B" mode, thinking I was just going to take the more modern
trunk version, before I realized that doing that simple edit (snipping out
the THIS code) would in fact be wrong.

> To make sure you haven't overlooked something, you can open up a diff
> view of the merged file compared to other, base or this, and look at the
> changes.  I don't do this for every single merge but if there are
> nontrivial conflicts it's a good idea to check.

Yes, thanks.

> "How far you have to look" doesn't have any simple answer then: in the
> worst case you have to look at the whole file but in practice almost
> always you just need to look at the blocks surrounding the conflict
> marks.

And in my case I actually didn't have to look at anything outside the
markers - all the code I needed was in there.  But I did need to go look
carefully at the complete trunk code to make sure I ended up with what I
wanted.

Thanks again,
Terry



More information about the bazaar mailing list