[PATCH V2] filemerge: add non-interactive internal:merge-local and internal:merge-other

Jordi Gutiérrez Hermoso jordigh at octave.org
Wed Aug 20 15:02:12 CDT 2014


On Mon, 2014-08-18 at 15:22 -0700, Pierre-Yves David wrote:
> We already have:
> 
>   - internal:other
>   - internal:local
> 
> It is not clear how user will be able to distinct between your two new 
> additions
> 
>   - internal:merge-other
>   - internal:merge-local

Well, they show up with brief explanations in "hg help merge-tools".
How could it be made clearer? I think the problem starts that
internal:other and internal:local are kind of confusing. A lot of
people, myself included, seem to think upon first meeting them that
they merge but resolve conflicts one way.

> Also, I can see a third type of tool that will take the content of side 
> X even when there was no manifest level conflict.

You mean, when there is no merging to be done? Then no merge tool
would get called for it.

> I think we need to think harder about a proper UI to hand all those
> case.

I can't think of such a UI that wouldn't break existing things. What
do you have in mind?

> > + at internaltool('merge-other', True)
> > +def _imergelocal(*args, **kwargs):
> 
> You forgot to update the function name.

Oh, wow. I was trying to figure out how this passed tests. I suppose
because the internaltool decorator closes over the function it's
wrapping when it puts it in the function list.

> Slicing the change to simple merge in a dedicated commit would make
> it simpler to review.

Okay, so two commits, one for simplemerge, one for the rest? I can do
that.

- Jordi G. H.




More information about the Mercurial-devel mailing list