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

[Pierre-Yves David]

On 08/27/2014 02:07 AM, Jordi Gutiérrez Hermoso wrote:
> On Tue, 2014-08-26 at 22:57 +0200, Pierre-Yves David wrote:
>>
>> On 08/25/2014 01:06 AM, Jordi Gutiérrez Hermoso wrote:
>>> # HG changeset patch
>>> # User Jordi Gutiérrez Hermoso <jordigh at octave.org>
>>> # Date 1407783206 14400
>>> #      Mon Aug 11 14:53:26 2014 -0400
>>> # Node ID 87bc71fdf83ba5ba2d85f8cf082819d30b93e31f
>>> # Parent  44ecb51c857da4cbfddcc8c1220747a477a96ac2
>>> filemerge: add non-interactive internal:merge-local and internal:merge-other
>>
>> I was expecting some trace of reflexion about the naming scheme of this
>> familly of tool. any advance on that?
>
> Yeah, I tried to think of something else, and I couldn't think of a
> better name for it. I asked around, nobody answered. I don't think the
> name is that bad. It's about as short as it can be while remaining
> descriptive. I honestly don't understand why you dislike the name, or
> what you have in mind instead.


There is at least 3 differents possible level we may want to resolve 
conflict

(1) manifest: always takes file from (other|local)
(2) file:     instead of merging take version from (other|local)
(3) chunk:    merge but resolve conflict in favor of (other|local)

case (2) is currently handled in core and called internal:other
You are proposing something for (3) called internal:merge-other

(1) is currentl unsupported and we have no name planned for it.


What I would like now from you is to actually think about the whole 
picture. Do we want to handle (1) ? is there other cases? Then come with 
a some proposal for a naming scheme of the possible case (this may 
involve drawing table).


What I current dislike about "internal:merge-other" is that if I hand 
"internal:other" and "internal:merge-other", he will have not idea about 
what each of those is doing. I also have no idea about how to name (1) 
after your new introduction for (3)

-- 
Pierre-Yves David