rust-matchers: implement `visit_children_set` for `FileMatcher` As per the removed inline comment, this will become useful in a future patch in this series as the `IncludeMatcher` is introduced. Differential Revision: https://phab.mercurial-scm.org/D7914

manifest: move matches method to be outside the interface In order to adequately smoke out any legacy consumers of the method, we rename it to _matches so it's clear that it's class-private. To my amazement, all consumers of this method really only wanted matching filenames, not a full filtered manifest. Differential Revision: https://phab.mercurial-scm.org/D8085

tags: use modern // operator for division Fixes a test on Python 3. # skip-blame only correcting a division operator, not a substantive change Differential Revision: https://phab.mercurial-scm.org/D8108

tags: fix some type confusion exposed in python 3 # skip-blame just b-prefix and %-format cleanup, no meaningful change Differential Revision: https://phab.mercurial-scm.org/D8107

rebase: remove some now-unused parent arguments Differential Revision: https://phab.mercurial-scm.org/D7829

rebase: remove some redundant setting of dirstate parents Since we're now setting the dirstate parents to its correct values from the beginning (right after `merge.update()`), we usually don't need to set them again before committing. The only case we need to care about is when committing collapsed commits. So we can remove the `setparents()` calls just before committing and add one only for the collapse case. Differential Revision: https://phab.mercurial-scm.org/D7828

rebase: don't use rebased node as dirstate p2 (BC) When rebasing a node, we currently use the rebased node as p2 in the dirstate until just before we commit it (we then change to the desired parents). This p2 is visible to the user when the rebase gets interrupted because of merge conflicts. That can be useful to the user as a reminder of which commit is currently being rebased, but I believe it's incorrect for a few reasons: * I think the dirstate parents should be the ones that will be set when the commit is created. * I think having two parents means that you're merging those two commits, but when rebasing, you're generally grafting, not merging. * When rebasing a merge commit, we should use the two desired parents as dirstate parents (and we clearly can't have the rebased node as a third dirstate parent). * `hg graft` (and `hg update --merge`) sets only one parent and `hg rebase` should be consistent with that. I realize that this is a somewhat large user-visible change, but I think it's worth it because it will simplify things quite a bit. Differential Revision: https://phab.mercurial-scm.org/D7827

rebase: stop relying on having two parents to resume rebase I'm about to make it so we don't have two parents when a rebase is interrupted (unless we're just rebasing on a merge commit). The code for detecting if we're resuming a rebase relied on having two parents, so this patch rewrites that to instead set a boolean when we resume. Note that `self.resume` in the new condition implies `not self.inmemory` (rebase cannot be resumed in memory), so that's why that part can be omitted. Differential Revision: https://phab.mercurial-scm.org/D7826

graphlog: use '%' for other context in merge conflict This lets the user more easily find the commit that is involved in the conflict, such as the source of `hg update -m` or the commit being grafted by `hg graft`. Differential Revision: https://phab.mercurial-scm.org/D8043

tests: add `hg log -G` output when there are merge conflicts The next commit will change the behavior for these. I've used slightly different commands in the different tests to match the surrounding style. Differential Revision: https://phab.mercurial-scm.org/D8042

revset: add a revset for parents in merge state This may be particularly useful soon, when I'm going to change how `hg rebase` sets its parents during conflict resolution. Differential Revision: https://phab.mercurial-scm.org/D8041

tests: add test of rebase with conflict in merge commit It doesn't seem like we had any tests of this. I think it's pretty weird that the two parents we're merging are not the working copy parents during the conflict resolution. Differential Revision: https://phab.mercurial-scm.org/D7824

rebase: always be graft-like, not merge-like, also for merges Rebase works by updating to a commit and then grafting changes on top. However, before this patch, it would actually merge in changes instead of grafting them in in some cases. That is, it would use the common ancestor as base instead of using one of the parents. That seems wrong to me, so I'm changing it so `defineparents()` always returns a value for `base`. This fixes the bad behavior in test-rebase-newancestor.t, which was introduced in 65f215ea3e8e (tests: add test for rebasing merges with ancestors of the rebase destination, 2014-11-30). The difference in test-rebase-dest.t is because the files in the tip revision were A, D, E, F before this patch and A, D, F, G after it. I think both files should ideally be there. Differential Revision: https://phab.mercurial-scm.org/D7907

nodemap: update the index with the newly written data (when appropriate) If we are to use mmap to read the nodemap data, and if the python code is responsible for the IO, we need to refresh the mmap after each write and provide it back to the index. We start this dance without the mmap first. Differential Revision: https://phab.mercurial-scm.org/D7893

nodemap: never read more than the expected data amount Since we are tracking this number we can use it to detect corrupted rawdata file and to only read the correct amount of data when possible. Differential Revision: https://phab.mercurial-scm.org/D7892

nodemap: write new data from the expected current data length If the amount of data in the file exceed the expect amount, we will overwrite the extra data. This is a simple way to be safer. Differential Revision: https://phab.mercurial-scm.org/D7891

nodemap: double check the source docket when doing incremental update In theory, the index will have the information we expect it to have. However by security, it seems safer to double check that the incremental data are generated from the data currently on disk. Differential Revision: https://phab.mercurial-scm.org/D7890

nodemap: track the total and unused amount of data in the rawdata file We need to keep that information around: * total data will allow transaction to start appending new information without confusing other reader. * unused data will allow to detect when we should regenerate new rawdata file. Differential Revision: https://phab.mercurial-scm.org/D7889

nodemap: track the maximum revision tracked in the nodemap We need a simple way to detect when the on disk data contains less revision than the index we read from disk. The docket file is meant for this, we just had to start tracking that data. We should also try to detect strip operation, but we will deal with this in later changesets. Right now we are focusing on defining the API for index supporting persistent nodemap. Differential Revision: https://phab.mercurial-scm.org/D7888

nodemap: add a flag to dump the details of the docket We are about to add more information to the docket. We first introduce a way to debug its content. Differential Revision: https://phab.mercurial-scm.org/D7887

nodemap: introduce append-only incremental update of the persistent data Rewriting the full nodemap for each transaction has a cost we would like to avoid. We introduce a new way to write persistent nodemap data by adding new information at the end for file. Any new and updated block as added at the end of the file. The last block is the new root node. With this method, some of the block already on disk get "dereferenced" and become dead data. In later changesets, We'll start tracking the amount of dead data to eventually re-generate a full nodemap. Differential Revision: https://phab.mercurial-scm.org/D7886

nodemap: keep track of the docket for loaded data To perform incremental update of the on disk data, we need to keep tracks of some aspect of that data. Differential Revision: https://phab.mercurial-scm.org/D7885

nodemap: introduce an explicit class/object for the docket We are about to add more information to this docket, having a clear location to stock them in memory will help. Differential Revision: https://phab.mercurial-scm.org/D7884

nodemap: keep track of the ondisk id of nodemap blocks If we are to incrementally update the files, we need to keep some details about the data we read. Differential Revision: https://phab.mercurial-scm.org/D7883

nodemap: provide the on disk data to indexes who support it Time to start defining the API and prepare the rust index support. We provide a method to do so. We use a distinct method instead of passing them in the constructor because we will need this method anyway later (to refresh the mmap once we update the data on disk). Differential Revision: https://phab.mercurial-scm.org/D7847

nodemap: all check that revision and nodes match in the nodemap More check is always useful. Differential Revision: https://phab.mercurial-scm.org/D7846

nodemap: add basic checking of the on disk nodemap content The simplest check it so verify we have all the revision we needs, and nothing more. Differential Revision: https://phab.mercurial-scm.org/D7845

nodemap: code to parse the persistent binary nodemap data We now have code to read back what we persisted. This will be put to use in later changesets. Differential Revision: https://phab.mercurial-scm.org/D7844

nodemap: move the iteratio inside the Block object Having the iteration inside the serialization function does not help readability. Now that we have a `Block` object, let us move that code there. Differential Revision: https://phab.mercurial-scm.org/D7843

nodemap: use an explicit "Block" object in the reference implementation This will help us to introduce some test around the data currently written on disk. Differential Revision: https://phab.mercurial-scm.org/D7842