largefiles: introduce a constant for 'lfmr' action It's better to use a dedicated constant instead of a string which makes pretty less sense. Differential Revision: https://phab.mercurial-scm.org/D8836

largefiles: override merge.emptyactions() to include `lfmr` I found it weird that we were not already doing this. I encountered this while using `emptyactions()` in mergeresult() class. Differential Revision: https://phab.mercurial-scm.org/D8835

merge: unify logic of couple of if-else's in manifestmerge() Right now manifestmerge() contains very nested if-else conditions and it's not easy to understand what is happening. I was looking for easy unifications and found these two. Differential Revision: https://phab.mercurial-scm.org/D8834

sparse: add comment for an if condition which I tried to refactor I tried to refactor this if condition and make it part of the if-else above but tests failed. I decided to add a comment about the check we are doing and why it's a separate if. Differential Revision: https://phab.mercurial-scm.org/D8833

mergeactions: use action constants instead of string values Having constants inplace of strings like 'c', 'cm' etc. makes it easier to understand the code. Differential Revision: https://phab.mercurial-scm.org/D8832

merge: use the new action based mapping introduced in mergeresult obj Before this patch, we have good number of instances of following types: ``` for f, (m, args, msg) in mresult.actions: if m == ACTION_X: do_something ``` We iterate over the whole list and then filter for a certain action. Previous patch introduced a action based mapping in mergeresult object. The above code now looks like: ``` for f, args, msg in mresult.getactions([ACTION_X, ...]): do_something ``` Differential Revision: https://phab.mercurial-scm.org/D8831

mergeresult: introduce action -> (filename, data, msg) mapping and related API Good number of places in code, we iterate over the actions dict which has filename as keys and filter based on the action. This patch introduced another mapping which has action as key. This will help in refactoring the code much more in upcoming patch. Differential Revision: https://phab.mercurial-scm.org/D8830

mergeresult: rename _actions to _filemapping This is done because we will be introducing another dict which introduces the same information but with action name as key. Differential Revision: https://phab.mercurial-scm.org/D8829

sparse: pass mergeresult obj in sparse.filterupdatesactions() (API) Not able to see much which can be improved in this function by passing in mergeresult object but for API consistency and no function directly touching actions dict, it sounds like a good idea. Differential Revision: https://phab.mercurial-scm.org/D8828

merge: filter actions before calling _resolvetrivial() In d49e490a9e85252886fd43258803bcad4fc88edb I made _resolvetrivial() to be called after upadting the sparse checkout. Looking at the code now, it seems to that me there is no need to even run _resolvetrivial() on actions which are filtered away. So let's update the actions before passing them into _resolvetrivial(). Differential Revision: https://phab.mercurial-scm.org/D8827

merge: introduce mergeresult.updateactions() and use it We don't want direct editing and access of mergeresult._actions because soon we will like to maintain data in other structures also. Differential Revision: https://phab.mercurial-scm.org/D8826

merge: pass mergeresult instead of actions in _checkunknownfiles() (API) Differential Revision: https://phab.mercurial-scm.org/D8825

merge: pass mergeresult obj instead of actions dict in _resolvetrivial() Differential Revision: https://phab.mercurial-scm.org/D8824

merge: pass mergeresult obj instead of actions in _filternarrowactions() We want to use rich mergeresult object and it's APIs instead of handling a dictionary. Differential Revision: https://phab.mercurial-scm.org/D8823