dirstate-v2: adds a flag to mark a file as modified Right now, a files with a file system state that requires a lookup (same size, different mtime) will requires a lookup. If the result of that lookup is a modified files, it will remains ambiguous, requiring a lookup on the next status run too. To fix this, we introduce a dedicated flag in the new format. Such flag will allow to record such file as "known modified" avoiding an extra lookup later. As None of the associate code currently exist in the status code, we do the minimal implementation: if we read a dirstate entry with this flag set, we make it as "ambiguous" so that the next status code has to look it up. The same as it would have to without this flag existing anyway. Differential Revision: https://phab.mercurial-scm.org/D11681

rhg: simplify split_metadata It turns out that it's possible to implement `FilelogEntry.into_data` on top of `split`, as proposed by @spectral. Differential Revision: https://phab.mercurial-scm.org/D11689

pyoxidizer: default to a meaningless release instead of hardcoding 5.8 This way we don't advertise the wrong version, or if we do it's really obvious. To be honest, I'm not even sure that `VERSION` should be optional, but I also have never used the packaging tools so far, this is simply something I saw. Differential Revision: https://phab.mercurial-scm.org/D11360

copy: recommend `--at-rev .` if target was added in parent commit If the target file was added in the working copy parent, it's much more likely that the user meant to use `--at-rev .` (to record the copy/rename in the that commit) than `--force` (to replace the just-added file by another file). Differential Revision: https://phab.mercurial-scm.org/D11667

fix: appease pyflakes and make unused variables more obvious pyflakes is complaining that `baserevs` is redefined by the list comprehension, and while this lint can be valuable, it's not actually a problem here. Differential Revision: https://phab.mercurial-scm.org/D11683

bookmarks: add a `ignore` variant of the bookmark mode This new mode allow to disable bookmark exchange with some path (or all path). Differential Revision: https://phab.mercurial-scm.org/D11677

bookmarks: add support for `mirror` mode to `incoming` This is more consistent. Differential Revision: https://phab.mercurial-scm.org/D11676

bookmarks: move the `mirror` option to the `paths` section A new `bookmarks` section with a `mirror` option have been added. That option has never been released yet. This new options is limited since it affect all paths without distinction. In case where a repository is interacting with multiple peers, being able to control behavior on a path basis can be quite valuable. In addition, having more variant of behavior would be interesting, especially a mode where no bookmark exchanged is tried at all. Such new mode (implemented later) make a lot of sense for configuration on a path-basis. Configuration of the default behavior is still possible through the usage of generic path configuration. The "old" config, becomes: [bookmarks] mirror=True becomes: [path] *:bookmarks.mode=mirror Differential Revision: https://phab.mercurial-scm.org/D11675

path: keep the path instance in the `pulloperation` This will allow more pull code to use the path options. Ideally we would modify the peer API to keep the path instance. However that is much more churn that I can deal with for my current goal: adjusting a user facing API for a new feature before we release it in the 6.0 changesets. So I am taking a shortcut that seems reasonable. Differential Revision: https://phab.mercurial-scm.org/D11674

path: return path instance directly from get_pull_paths This means the caller has to do a bit more work, however it give access to the `path` instance and the information it contains. Differential Revision: https://phab.mercurial-scm.org/D11673