On Mon, Apr 7, 2014 at 8:01 PM, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
> Stefan Sperling wrote on Mon, Apr 07, 2014 at 18:00:21 +0200:
>> A new --file-merge option is the simplest way of solving this
>> problem I could come up with. It maps the options provided by
>> the internal merge tool to a command line flag:
>>
>> --file-merge ARG : Set a pre-defined choice ARG for the built-in file
>> merge tool, which otherwise prompts interactively.
>> --file-merge applies to text conflicts only and
>> overrides the --accept option for file merges.
>> ARG is any of 1, 2, 12, 21, e1, e2, or eb:
>> (1) use their version, (2) use your version,
>> (12) their version first, then yours,
>> (21) your version first, then theirs,
>> (e1) edit their version and use the result,
>> (e2) edit your version and use the result,
>> (eb) edit both versions and use the result
>>
>> But it's just an ad-hoc idea, so I would like to get some feedback.
>> I'm curious if anyone else has other ideas.
>>
>
> If you're just "automating answering the prompt that follows the (m)
> choice in the interactive resolver", have you considered a direction
> such as
>
> --accept m/eb
> or
> --accept m=eb
>
> ? They both have a backing intuition ('m/eb' is more specific than 'm',
> like a directory tree; 'm=eb' is a 'named argument with an optional
> value' syntax, as in Python method definitions).
>
> My main point is to hang the 'm\n12\n' syntax off of the 'm' option.
> Somehow.
>
I also prefer making the --accept option somehow more powerful,
instead of adding another option.
Another thing that crossed my mind: what if we want to add some
similar defaults for tree-conflict-resolution some day? Would we end
up with:
--file-merge=21 --tree-merge=blahblah
?
Not sure if that's a good path to go down. Using some more powerful
syntax for --accept might make it easier to extend this in the future
(I know, it's a bit hard to reason about the
still-unknown-mysterious-ways-we-will-someday-resolve-tree-conflicts,
but it doesn't hurt to think about extensibility).
--
Johan
Received on 2014-04-07 23:27:40 CEST