[PATCH] merge: add resolve --prep, which outputs conflicted comparison files

[Jun Wu]

Excerpts from Phil Cohen's message of 2017-02-24 14:54:00 -0800:
> Hi Jun,
> 
> Interesting, thanks. So if I understand correctly, if --tool accepted
> a Python function, to replicate the functionality described here, the
> user could write a simple script that wrote out the four* versions to

Probably just three, because the Python code could call internal functions
to render the markers easily.

> some location on disk and printed their paths as JSON (as you noted,
> they could also output the contents directly in some encoding, but
> that's up the user.)
> 
> It sounds like the issue of `resolve` always overwriting the file in
> the working copy is a nuisance, and will probably be more of one in
> the future if we people use #1 to extract information about the merge
> as we are doing. It might not be an issue for us but we should
> probably fix/change that too?

As discussed offline, I think the reason that hg writes to the working copy
is to provide the merge tool an initial state of the merge resolution
result, and reads from it as the output of the resolution if the tool
reports merge success.

If we have passed the contents directly like:

  def mergefunc(ui, repo, basefctx, localfctx, otherfctx)

It becomes unnecessary to write the working copy first, because the initial
merge state is just "basefctx". And if "mergefunc" is supposed to return a
"fctx-like" object, we can avoid reading from the working copy too.
Therefore the working copy is not touched during the process. The merge tool
itself could write to the working copy though.

Anyway, I think we can get the Python merge function support first (which
seems to be relatively straightfoward), and then decide what's the behavior
of the Python merge function we want:

  - does it render conflict markers?
  - does it write temp files or just produce a giant json result?
  - does it read/write working copy or not?

> [Let me know if this email is poorly formatted, it's my first reply to
> the list.]

The format looks good!
 
> *Including generating the version with the conflict markers.