hg-core: remove useless code (D8958#inline-14988 followup) Differential Revision: https://phab.mercurial-scm.org/D9099

hg-core: minor docstring update (D8958#inline-14991 followup) Differential Revision: https://phab.mercurial-scm.org/D9097

hg-core: minor code style change (D8958#inline-14986 followup) Differential Revision: https://phab.mercurial-scm.org/D9096

hg-core: Explain offset override of first revision (D8958#inline-14992 followup) Differential Revision: https://phab.mercurial-scm.org/D9095

hg-core: minor code style change (D8958#inline-14993 followup) Differential Revision: https://phab.mercurial-scm.org/D9083

changing-files: move default constructor value to None According to Augie Fackler, using tuple as default value confuse PyType when actual values are passed at init time. Differential Revision: https://phab.mercurial-scm.org/D9086

rust: format with rustfmt I suppose I ran the formatter on the tip but not on every patch. Differential Revision: https://phab.mercurial-scm.org/D9093

merge: store cases when a file is absent post merge in commitinfo Some merges can result in file being absent form working directory. This can be one of file was kept deleted or file was removed by merge code. User might revert the file back before committing. In such cases we will like to have better handling and create new filenodes. We store this info in mergestate as commitinfo so that we can use it while committing to create new filenode if required. Differential Revision: https://phab.mercurial-scm.org/D9003

tests: add some more debugmergestate calls in `test-merge-criss-cross.t` Differential Revision: https://phab.mercurial-scm.org/D9029

commit: force create a new filenode if it was set in mergestate by merge For reasons mentioned in previous commits, we will like to forcefully create a new filenode sometimes. Combination of this patch and previous one, we fixed a case in `test-merge-combination.t`. This does not yet results in conflict where it should, I need to investigate more about what's happening as it should be a change-delete conflict now. Differential Revision: https://phab.mercurial-scm.org/D8989

merge: store commitinfo if these is a dc or cd conflict delete-changed or changed-delete conflicts can either be resolved by mergetool, if some tool is passed and using or by user choose something on prompt or user doing some `hg revert` after choosing the file to remain conflicted. If the user decides to keep the changed side, on commit we just reuse the parent filenode. This is mostly fine unless we are in a distributed environment and people are doing criss-cross merges. Since, we don't have recursive merges or any other way of describing the end result of the merge was an explicit choice and it should be differentiated from it's ancestors, merge algo during criss-cross merges fails to take in account the explicit choice made by user and end up with a what-can-be-said-wrong-merge. The solution which we are trying to fix this is by creating a filenode on commit instead of reusing the parent filenode. This helps differentiate between pre-merged filenode and post-merge filenode and kind of tells about the choice user made. To implement creating new filenode functionality, we store info about these files in mergestate so that we can read them on commit and force create a new filenode. Differential Revision: https://phab.mercurial-scm.org/D8988

mergestate: update _stateextras instead of reassinging `merge.applyupdates()` can store extras for a file and _stateextras may not be empty always. Hence reassigning loses the old values. We can directly update like this because we switched to using `collections.defaultdict` for `_stateextras` sometime ago.

tests: add some debugmergestate calls in `test-merge-criss-cross.t` This will help notice the change in upcoming patches much better. Differential Revision: https://phab.mercurial-scm.org/D9028

tests: add few debugrevlogindex and a log call to see changes in next test In upcoming patches, we will create a new filenode in couple of cases. Let's add some debugrevlogindex and a log call so that we can observe those changes better. Differential Revision: https://phab.mercurial-scm.org/D8987

merge: disable `m2-vs-ma` optimization if new filenode config is true The `m2-vs-ma` optimization filters out the file which have not changed between second parent and the ancestor of the merge. This results in the m1-vs-m2 diff not processing those files. These files will be required when we are creating new filenode for salvaged cases as we need to track them to store in mergestate that file can be salvaged. Differential Revision: https://phab.mercurial-scm.org/D9027

configitems: add a new config option to control new filenode functionality This series is adding functionality where we can force create a new filenode for some files on a merge-commit. This is meant to represent an explicit choice made by user and hence distingusing the file in the merged commit with the file in parent by creating a new filenode instead of using the parent one. This introduces a experimental config option under which this functionality will be hidden. A new testcase is added in tests/test-merge-criss-cross.t to test the new functionality while making the option does not break other scenarios. Differential Revision: https://phab.mercurial-scm.org/D9026

git: add test showing `hg commit -i` working on a git repo Shows `hg commit -i` working on a git repo via the `git` extension. Adds working directory changes to files `alpha` and `beta`, then selects only `alpha` changes and commits them. As of now this would fail for a filename that includes uppercase characters due to the lack of case folding support in the extension. Differential Revision: https://phab.mercurial-scm.org/D9081

merge: replace calls to hg.updaterepo() by merge.update() The former no longer buys us anything. Differential Revision: https://phab.mercurial-scm.org/D9067

merge: add a higher-level update() for the common `hg update` use case This is different from the `update()` function that I just made private. The new function is specifically for the normal `hg update` use case. It doesn't do a merge and it doesn't do a clean (forced) update. Differential Revision: https://phab.mercurial-scm.org/D9066

sidedata: simply read p2copies files from the `ChangingFiles` object

sidedata: simply read p1copies files from the `ChangingFiles` object

sidedata: simply read removed files from the `ChangingFiles` object

sidedata: simply read added files from the `ChangingFiles` object

sidedata: add a `decode_files_sidedata` function Right now the function mostly gather existing code to build a consistent object. However having this function allow us prepare all user code independently from the actual side data format change (and associated encoding/decoding changes) Strictly speaking, we could not need to passe the sidedata explicitly since we have access to it though the `changelogrevision` object. However, the short term goal is to drop that first parameter to only pass the sidedata binaries.

changelog: add a `changes` property on `changelogrevision` For the sidedata storage we are moving toward "all in one" block containing the equivalent of a "ChangingFiles" instance. We do various refactoring beforehand to prepare the usage of theses new data in the code. Since the object use slots, the "property cache" tricks cannot be used, and we cache the value manually.

sidedata: rename `encode_copies_sidedata` to `encode_files_sidedata` We are storing more than copies information, so lets make it clear.

log: pass around --rev option by walkopts

log: parse --limit option by logcmdutil.parseopts()