On 2/27/17 11:01 AM, Jun Wu wrote:
Excerpts from Durham Goode's message of 2017-02-27 10:41:39 -0800:
On 2/24/17 4:04 PM, Jun Wu wrote:
Excerpts from Durham Goode's message of 2017-02-24 15:42:34 -0800:
Maybe I don't understand your proposal. The current merge-tools are
invoked once per file. Would this python merge-tool be invoked in some
other way where it's given the full conflict state at the beginning then
it can do what it wants? So we'd special case python merge tools to be
Actually it's a good question. I think it's more consistent if being called
per-file. But I see that'll be problematic about "when is it the last file?"
That probably requires an extra parameter about how many files are left.
a little different? We could just define a internal merge tool called
'internal:json' or something and skip the whole extensibility thing.
That's possible. Although I'm not sure if it's a good idea or not. Since we
have ":dump" already, maybe name it something like ":dump-json". I guess the
most difficulty part to reach agreement is to define the json schema - the
merge state includes things like executable bit, symlink, etc. So I'd rather
to put this outside core from the beginning.
If it ends up outside core, it's such a minor feature we'll likely never
do the work to move it in to core. I don't think the json schema will be
that big of a deal. The kinds of data we need are pretty clear: file
content at various versions, file flag at various versions, kind of
conflict.
Also, how does the merge tool communicate to the caller the json
results? Write it to a file? Or does the merge tool have the ability to
print to stdout?
It has ui and repo.wvfs so it could do whatever it wants.
Therefore the signature could be something like:
def mergefunc(ui, repo, basefctx, localfctx, otherfctx, index, total):
raise ... # merge failure
return None # alternative, merge failure
return fctx-like # merge success
If we want to do the ":dump-json" thing, it could be like:
state = {}
def merge(....):
if index == 0:
state.clear()
state[basefctx.path()] = ....
if index == total:
ui.write(json.dumps(state))
return None # report failure
What if we drop the --prep and just introduce '--tool
internal:dump-json' as the switch that gets us to this code path. So
that gets it in core without needing much of a rewrite. If you're
worried about deciding on a schema, we can mark it as experimental in
the documentation.
I think that's a possibility. Note that there are 2 possible output formats:
1. Raw file contents, without conflict markers
2. Sliced file segments, with conflict indicators
I guess we want 2. The format is slightly more complex than 1. As long as it
express all the related information unambiguously, I'd be fine with it.
Do you mean outputting the actual file content in the json? I was
thinking of having just the paths to the file contents be in the json.
That way we don't have to json escape a bunch of binary data if we
output conflicting binary files (which is an eventual use case).
For raw vs slice, I think having the four raw files (yours, mine, base,
output file which starts with conflict markers in it) makes the most
sense from the point of view of a merge tool consuming this data. I
don't think we should require the consumer to parse the conflict marker
file. I'm not even sure they could 100% correctly parse the file if the
file contained text that looked like conflict markers but was actually
part of the file.
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
