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