graphlog: use '%' only if there are *unresolved* conflicts In 14d0e89520a2, I made graphlog use '%' for the "other" context when there's an existing merge state. However, that has confused many people because it shows up even if all conflicts are already resolved, which makes it show up even after e.g. `hg update -m` with automatically resolved conflicts. This patch makes it so we show the '%' only if there still unresolved conflicts. This patch replaces my earlier attempt in D8930, where I decided to automatically clear the mergestate if there are no remaining conflicts. That had the problem that it wouldn't let the user re-resolve the conflicts using `hg resolve`. Note that an in-progress "proper" merge (one that will result in a commit with two parents, such as after `hg merge`) will already have two dirstate parents before the commit happens. That means that both sides of the merge will get drawn as '@' in the graph, since "is dirstate parent" takes precedence over "is involved in merge conflict". Differential Revision: https://phab.mercurial-scm.org/D9007

merge: show number of ancestors in bid merge debug notes A good number of times, we don't generate an action for a file in manifestmerge() which can result in bid merge doing the wrong thing. Mentioning the number of ancestors from which we are bidding will help spot such cases where we are not returning an action. Differential Revision: https://phab.mercurial-scm.org/D8967

debugmergestate: sort extras before printing Prevents flaky output. Differential Revision: https://phab.mercurial-scm.org/D8986

debugmergestate: show extras for files which are not in mergestate With recent changes and future changes, we will like to store extras information about files which were merged automatically. Hence, we will have merge extras for files which are not in the mergestate. Differential Revision: https://phab.mercurial-scm.org/D8942

tests: update lockdelay.py to handle the `wait` argument Spotted by a future change.

commit: pass mergestate into _filecommit() instead of re-reading it mergestate reading although cheap is not free. Let's read mergestate once on top and pass it into `_filecommit()`. In upcoming patches, we will be reading mergestate more in `_filecommit()`. Differential Revision: https://phab.mercurial-scm.org/D8984

py3: fix bytes and str mixup in run-tests Differential Revision: https://phab.mercurial-scm.org/D9009

hg-core: fix some `clippy` warnings Differential Revision: https://phab.mercurial-scm.org/D8957

rhg: print error message when argument parsing fails Differential Revision: https://phab.mercurial-scm.org/D8956

rhg: fix `clippy` warnings Differential Revision: https://phab.mercurial-scm.org/D8955

rhg: pass `ui` to `Command` `run` Allow implementation of `From<clap::ArgMatches> for Command` Differential Revision: https://phab.mercurial-scm.org/D8954

rhg: add harness tests for rhg files Differential Revision: https://phab.mercurial-scm.org/D8873

rhg: make output of `files` relative to the current directory and the root This matches the behavior of `hg files`. The util is added in `hg-core` instead of `rhg` because this operation could be useful for other external tools. (this was definitely not prompted by rust issue #50784, I swear) Differential Revision: https://phab.mercurial-scm.org/D8872

tags: take lock instead of wlock before writing hgtagsfnodes1 cache This cache is shared across stores and hence we should take store lock before writing to it. Otherwise there will be race where one share with wlock is writing to this cache and other share with wlock is trying to read it simultaneously. Differential Revision: https://phab.mercurial-scm.org/D9001