Question about internal:fail

[Mike Meyer]

On Wed, 30 Nov 2011 20:37:18 -0500
Greg Ward <greg-hg at gerg.ca> wrote:

> On Wed, Nov 30, 2011 at 12:47 PM, Mike Meyer <mwm at mired.org> wrote:
> >> > The scenario I want happens *every time I merge*. That is *not*
> >> > "pretty rare". If it were, it wouldn't be an issue.
> >> It doesn't happen for most other people so... use another revision
> >> control system, then.
> >
> > Sure. Can you suggest a DVCS that provides good control during a
> > merge?  I haven't found one, which leaves me writing one.
> >
> > It'd be easier to fork mercurial.
> 
> And even easier to implement the feature you want, which is some
> control over the manifest merge. It's right there in
> mercurial/merge.py: manifestmerge().

Well, fork did presume that such a change wouldn't be accepted by the
community.

> I think Sune was a bit over-the-top in suggesting "get another version
> control system". Mercurial's not 100% perfect, but it's pretty darn
> good. If you do something about this problem, then it'll edge a little
> closer to perfect.
> 
> Idea #1: write an extension that overrides manifestmerge() with your
> preferred "pick local" or "pick other" semantics. As a baby-steps
> exercise, you could do one extension that implements "pick local" and
> another that implements "pick other". Then you'd have to enable one
> extension or the other every time you merge, depending on the
> behaviour you want. Then you need to figure out how to unify them
> (easy) and expose a knob to the user letting them specify which
> manifest merge algorithm they want (not so easy, given the variety of
> places where Mercurial invokes merge).

I'd be perfectly happy with an extension. In fact, it might be the
most trivial extension ever written, since I can do what I want if I
can just get it to always leave things unresolved.

> BTW, I'm curious about why you always need a "pick local" or "pick
> other" merge strategy. That's ... umm ... not really *merging* then,
> is it? I mean, if you always overrule the work done on one branch with
> the other branch, then why bother merging them? Why even bother
> implementing both?

That's not what I want. What I *really* want is a way to use
resolves machinery on every file that differs between the two
branches. The original idea was to use internal:fail to start
that. That was when I discovered that it wasn't called under
conditions when I thought it should be. That's why the subject line is
about internal:fail.

In poking at this, I found an entry in the mercurial wiki entry
(http://mercurial.selenic.com/wiki/TipsAndTricks) recommending using
internal:local and internal:other, which only worked if the assumption
I had made about the behavior of internal was correct (and I've since
corrected it), so I pointed out that it also failed in those
cases. Which people seem to have fastened on as the use case I had in
mind.

	<mike
-- 
Mike Meyer <mwm at mired.org>		http://www.mired.org/
Independent Software developer/SCM consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org