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