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