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 _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
