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

[Durham Goode]

On 2/27/17 11:09 AM, Danek Duvall wrote:
> Durham Goode wrote:
>
>> On 2/24/17 4:10 PM, Danek Duvall wrote:
>>
>>> Is that the central issue?  That is, you want to run a tool once over all
>>> unresolved files, rather than one at a time?
>>>
>>> It seems like perhaps a new config option for merge-tools could indicate
>>> that it takes multiple files.  Then the question is whether the tool should
>>> know how to generate the list of unresolved files and the various versions
>>> of them that are involved in the resolution, or whether mercurial should
>>> compute all that and pass it to the tool in some fashion.
>>>
>>> Likewise on the other end, the tool will need to communicate back to
>>> mercurial which files are now considered resolved, and which ones aren't.
>>>
>>> Or am I misunderstanding what you're trying to do?
>>>
>>> Danek
>>
>> The high level goal is we want to provide an entire conflict experience via
>> an IDE, so we need all data related to the merge conflicts (content of files
>> at relevant revisions; type of conflict, like changed vs deleted, or
>> directory vs file, or executable vs symlink) available at once, and not
>> during a blocking Mercurial command.  The current merge tool logic doesn't
>> handle any of those requirements.
>
> So why not consider this situation to be a new type of merge tool flag, and
> then define the protocol for that kind of tool to be a commandline argument
> of a json file with the necessary data?  It seems like both the original
> proposal (emit json with a custom flag) and the updated one (emit json with
> a custom merge tool) are less flexible, and involve more manual effort (you
> still have to run your tool manually and pass it that json blob).

Do you mean something like, add a --merge-tool-json flag and mercurial 
executes the specified tool by passing a file path to a json file with 
the data we've been talking about? In our scenario, where an IDE wants 
to receive all the conflict data and act on it asynchronously from 
mercurial's resolution logic, doing this using your proposal would mean 
we'd have to create a bash script or something that just copies the json 
file it's passed to some other location so the IDE can read that file 
after 'hg resolve --merge-tool-json simplecopytool.sh' exits (or 
otherwise communicates the information to the IDE somehow).

We could always add that later if other use cases show that to be a more 
intuitive api.

> Besides, you can run "hg resolve -l" and "hg cat -r ..." while in the
> middle of the merge, so I'm not sure what you mean by the merge tool logic
> doesn't allow you to do that.  Is it that "hg resolve -l" doesn't give you
> enough data about what metadata is changing?

hg resolve doesn't give us information about the various versions of the 
file or information about the type of conflict, and even if it did give 
us the hashes of those versions, shelling out to hg cat for each one is 
excessively slow in large repos.