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