Question about internal:fail

Mike Meyer mwm at mired.org
Thu Dec 1 17:47:00 CST 2011


On Fri, 2 Dec 2011 00:24:50 +0100
Dennis Brakhane <brakhane at googlemail.com> wrote:

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

I think that's close enough.

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

That's not complete, in that it leaves out one of the differences
between the two: if B changed a file I haven't touched, update to
their change.

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

I, on the other hand, think of two lines of development, and want to
make sure that two different fixes to the same issue don't wind up in
the result (which generally means you get a new bug), among other
things.

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

Yes. I figured that would be an external merge tool to invoke via
resolve.

> 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?

Right. I'm paranoid about merges. Not as paranoid as some, but
apparently more so than most.

       <mike


More information about the Mercurial mailing list