merge: pass commitinfo to applyupdates() and get it stored in mergestate This patch passes the commitinfo calulcated in manifestmerge() to applyupdates() so that it can be read there and stored in mergestate. On commit, we can read mergestate for such information and act accordingly. This patch also makes ACTION_GET_OTHER_AND_STORE not required anymore. Next patch will remove the messy code surrounding it. Differential Revision: https://phab.mercurial-scm.org/D8743

merge: introduce 'commitinfo' in mergeresult 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. Upcoming patches will try to work on in this area and make things easier. Differential Revision: https://phab.mercurial-scm.org/D8742

merge: return a mergeresult obj from manifestmerge(), calculateupdates() (API) Earlier, manifestmerge() and calculateupdates() returns a tuple of three things. I wanted to add one more thing to return value. Introducing a special class which represents results of a merge will help understand better and also ease adding new return values. Differential Revision: https://phab.mercurial-scm.org/D8799

packaging: delete unnecessary updating of `dirs` list The `dirs` list is not used and it seems it also wasn't used when this code was added in 395b0e132836 (Don't copy hidden files/directories during `setup.py install`, 2009-07-14). Differential Revision: https://phab.mercurial-scm.org/D8857

packaging: make "mercurial.defaultrc" a key in package_data Before this patch, we had a `mercurial` key with a `defaultrc/*.rc` value. It seems more correct to have a `mercurial.defaultrc` key with a `*.rc` value since `mercurial.defaultrc` it became a pacakge in 1390bb81163e (help: get helptext/ data from `resources` module if available, 2019-12-12). Differential Revision: https://phab.mercurial-scm.org/D8856

templatespec: use new factory functions in hooklib Differential Revision: https://phab.mercurial-scm.org/D8853

templatespec: use new factory functions in logcmdutil Differential Revision: https://phab.mercurial-scm.org/D8848

templatespec: move check for non-unicode to lower-level function Now that we have the factory functions, it makes sense to have the check there. Differential Revision: https://phab.mercurial-scm.org/D8847

templatespec: logcmdutil.templatespec() gets either template or mapfile The callers of the function already never pass (non-`None`) values for both, so let's check that and call the new factory functions. Differential Revision: https://phab.mercurial-scm.org/D8846

templatespec: create a factory function for each type there is Most of the arguments to the `templatespec` constructor are mutually exclusive, so each combination creates a different type of templatespec. Let's clarify that by creating factory functions. I've left the callers in `logcmdutil` unchanged for now because they are more complex and `logcmdutil.templatespec()` is slightly higher level in that it is specific to changesets. My larger goal is to add support frozen binaries (specifically PyOxidizer) by adding a specific type of `templatespec` for built-in templates. That will get its own factory function. Differential Revision: https://phab.mercurial-scm.org/D8845