[PATCH 11 of 13] merge: return 'commitinfo' from manifestmerge() and calculateupdates() (API)

[Pulkit Goyal]

On Sun, Jul 19, 2020 at 3:34 PM Yuya Nishihara <yuya at tcha.org> wrote:
>
> On Fri, 17 Jul 2020 14:29:32 +0530, Pulkit Goyal wrote:
> > # HG changeset patch
> > # User Pulkit Goyal <7895pulkit at gmail.com>
> > # Date 1594723868 -19800
> > #      Tue Jul 14 16:21:08 2020 +0530
> > # Node ID 9fd8b89eee7e32ce4f3703d423cc320dec64da86
> > # Parent  6a87141b0721d719fcc3b8bb94743eda1a120c17
> > # EXP-Topic mergestate-refactor
> > merge: return 'commitinfo' from manifestmerge() and calculateupdates() (API)
> >
> > commitinfo will be used to pass information which is required on commit phase
> > from the merge phase.
> >
> > One common example is, merge chooses filenode from second parent and we need to
> > tell commit to choose that. Right now this one and related cases are not very
> > neatly implement and there is no clear line on how to pass on such information.
>
> Is this commitinfo an orthogonal concept to the actions? If that's true, this
> change makes sense, but if not, I think commitinfo[f] == b'other' can be a third
> argument of ACTION_GET.

Yes, this whole work is meant to refactor and draw lines between
various things. commitinfo will be the information which should be
stored in mergestate and then used at commit time. ACTION_* should be
meant for dirstate related things or actions which needs to be
performed resulting in some mergerecords.

>
> Just asking because I didn't review the previous attempt.

Now after spending a good amount of time with this code, it feels to
me that my old approach was a hack, non-extensible one which (ab)used
ACTION_* to achieve a quick bug fix.