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.
> Among other ideas discussed on IRC where:
>
> - Currently the file merge tool is only reachable from the interactive
> conflict resolution handler. We could split the internal merge tool
> off into a seperate program shipped with Subversion (let's call this
> svn-file-merge for this discussion) so it could be run standalone:
From the peanut gallery, un-special-casing the internal merge sounds
like a good general direction. But I haven't followed the discussion in
detail. (And in particular, "un-special-casing" is not the same thing
as "spinning off into a separate binary"; perhaps one implies the other,
but they might be independent.)
HTH
Daniel
Received on 2014-04-07 20:02:26 CEST