[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