Question about internal:fail

[Dennis Brakhane]

On Thu, Dec 1, 2011 at 8:45 PM, Mike Meyer <mwm at mired.org> wrote:
> foo2 isn't the issue. foo is the issue. On the Branch 1, it's:
>
>    Testing
>    hello
>
> On Branch 2, foo is still just:
>
>    Testing

Ah, I think I understand.

>
> That sure looks like a file that differs to me! And that's the one I
> want to get to with the resolve machinery.

If I understand you correctly, you and hg have different opinions on
what merge is supposed to do. (Let's call them mm merge and hg merge)

mm merge B:

Create a diff of (branch) A's current snapshot of (tracked) files, with
B's snapshot. See what files differ and then do a three-way merge for
each of them, using the common ancestor.

hg merge B:

Fetch all *changes* that B made since the branching point, that I don't have.
If they touch the same files as some of my changes, do a three way merge
for each file.

(I think your merge could get ill-defined when than one changeset is
involved, but
that's not interesting ATM). In case of a single changeset, the two merges
will produce identical results if no "internal:fail" is used. If it is
used, your merge
would in fact produce the result you expect.

The question is: why do you want to let merge work this way? Normally, I think
when you merge, you really are interested in the changes the other party did
(to the code or whatever) and want to get those changes into your code base.

The only reason I can think of is that you actually want to have a
tool to determine
the complete differences (or conflicts, as you might call them) between the two
"snapshots" you are merging to help you decide on how to do a meaningful merge.

If that's what you want, "hg diff 1 2", might help as it shows you the
differences
between the two snapshots. But I assume that's not exactly what you
are looking for,
you are looking for a kind of 3-way-diff between common base, r1 and
r2, correct?

Sorry if I completely misunderstood you. If this is the case, could
you provide an
actual example or use case (because in this case, the current examples
are apparently
too simplified or contrieved to show the real problem; or I might just
be too silly to understand ;))