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

Durham Goode durham at fb.com
Mon Feb 27 13:35:56 EST 2017



On 2/24/17 4:10 PM, Danek Duvall wrote:
> Durham Goode wrote:
>
>>
>>
>> On 2/24/17 3:25 PM, Jun Wu wrote:
>>> Excerpts from Durham Goode's message of 2017-02-24 15:18:40 -0800:
>>>> On 2/23/17 2:57 PM, Jun Wu wrote:
>>>>> Congratulations on your first patch to the list!
>>>>>
>>>>> But I think we have better ways to achieve the same goal that we may prefer
>>>>> them to this patch.
>>>>>
>>>>> 1) Better way to provide conflicted file contents - in-python merge tools
>>>>>
>>>>>  From a high-level, the patch tries to solve the problem:
>>>>>
>>>>>    - Get all paths and file contents involved in merge conflict resolution
>>>>>      in an efficient way.
>>>>>
>>>>>  We have "--list" and "--tool" already to fetch the data in a less efficient
>>>>>  way. I'm not a big fan of a new flag doing what we can do today.
>>>>>
>>>>>  I think a better to achieve the "efficient" goal is to make "--tool"
>>>>>  accept Python functions, just like what we do for hooks. If the signature
>>>>>  of the Python function accepts file contents directly, we can even avoid
>>>>>  writing temporary files - even more efficient than this patch.
>>>>
>>>> While that way may be more generic, and potentially more efficient in
>>>> some cases, it puts a larger burden of understanding on the consumer.
>>>> They would have to learn about Mercurial internals (or at least the api
>>>> for the hook), write a python script, and package that script into their
>>>> deployment.  Given that Mercurial already has knowledge of what data
>>>> merge tools need, I think it's reasonable to just have an interface that
>>>> prints that data for simple consumption.
>>>
>>> That shouldn't be an issue if we ship the Python merge function that
>>> generates the format they want - what they need is to just put a single line
>>> of config, like "merge-tool=somemod:jsonexport"
>>
>> Maybe I don't understand your proposal.  The current merge-tools are invoked
>> once per file.
>
> 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.

For communicating back to Mercurial, 'hg resolve --mark file1 file2' 
already exists and is sufficient.


More information about the Mercurial-devel mailing list