Unexpected result from bzr merge: line missing?

[Martin Pool]

On 29 July 2010 09:24, Terry Jones <terry at jon.es> wrote:

> Martin> If you run 'bzr remerge --show-base file.py' and post the relevant
> Martin> excerpt it might help explain that.
>
> It looks like:
>
>            if about:
> <<<<<<< TREE
>                about = guessValue(about)
>                if about:
>                    result.about = about
> ||||||| BASE-REVISION
>                result.about = about
> =======
>                result.about = about.encode('utf-8')
>>>>>>>> MERGE-SOURCE

This is a pretty nice example:

Originally, the local 'about' was just assigned to result.about.

In merge-source, someone decided to utf-8 encode it.

In the destination, someone decided to guessValue and assign only if
the result was non-null.

How to resolve this depends on a human assessment.  They don't seem
inherently contradictory but perhaps you need to check if guessValue
is doing encoding, or whether encoding should be done before or after
calling that.

> I guess there's something I'm not understanding then.  My understanding was
> that when I looked at any file with conflicts in it, I'd see something
> like:
>
>    common1
>    <<<<<<< TREE
>    text1
>    =======
>    text2
>    >>>>>>> MERGE-SOURCE
>    common2
>
> and that I could either use common1/text1/common2 to have things as they
> were in my current tree, or I could use common1/text2/common2 to have
> things as they were in the merge source.  I've always resolved conflicts
> that way, usually selecting either text1 or text2 and deleting the other,
> and of course occasionally doing some work to manually merge things *within
> the <<< >>> block*.
>
> But in the current example it's not as simple, because simply removing
> text1 does *not* result in me having the code as it was in the merge
> source. The "about = guessValue(about)" line (416 in the merge source,
> i.e., the trunk) would then be missing.
>
> So in this case, the correct resolution (which is not complicated, it's
> simply to have what was in the merge source) requires me to consider code
> that falls *outside* the
>
>    <<<<<<< TREE
>    text1
>    =======
>    text2
>    >>>>>>> MERGE-SOURCE
>
> block, which I find a bit disturbing / counter-intuitive. How far back in
> the common1 text (or how far forward in the common2 text) am I supposed to
> look before I can be confident I've not overlooked something that bzr merge
> didn't flag for me?
>
> I hope I'm being clear - apologies if not, and thanks again for the reply.

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.  Actually understanding whether there is a
semantic conflict is probably hard for a computer.

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.

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.

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

Hope that helps,
-- 
Martin