fix: mark -r as advanced See the previous patch for reasoning. I planned to even mark it deprecated, but someone (timeless?) on the #mercurial IRC channel said they sometimes wanted to use `-r` with its existing semantics. Differential Revision: https://phab.mercurial-scm.org/D8288

fix: add a -s option to format a revision and its descendants `hg fix -r abc123` will format that commit but not its descendants. That seems expected given the option name (`-r`), but it's very rarely what the user wants to do. The problem is that any descendants of that commit will not be formatted, leaving them as orphans that are hard to evolve. They are hard to evolve because the new parent will have formatting changes that the orphan doesn't have. I talked to Danny Hooper (who wrote most of the fix extension) about the problem and we agreed that deprecating `-r` in favor of a new `-s` argument (mimicing rebase's `-s`) would be a good way of reducing the risk that users end up with these hard-to-evolve orphans. So that's what this patch implements. Differential Revision: https://phab.mercurial-scm.org/D8287

fix: move handling of --all into getrevstofix() for consistency Differential Revision: https://phab.mercurial-scm.org/D8286

rust-status: add trace-level logging for Rust status fallback for debugging The added `log` crate is already a sub-dependency. Differential Revision: https://phab.mercurial-scm.org/D8300

hg: make _local() behave consistently on Python 3.8 (issue6287) Python 3.8 makes os.path.isfile quietly eat "path invalid" errors and return False instead of allowing the exception to propagate. Given that this is a change from 2018 (sigh) and it's mentioned in the release notes (double sigh) we're definitely too late to complain to Python about the behavior change, so open-code part of os.path.isfile() in this method so we can catch invalid-path errors and handle them appropriately. I confirmed that posixpath and ntpath both delegate to genericpath, which uses os.stat() under the covers. Differential Revision: https://phab.mercurial-scm.org/D8302

remotefilelog: add fake heads() method that allows viewing a file in hgweb As best I can discern, this is not going to hurt anything, but it'll cause a couple of options to exist in the UI that are nonsensical. That seems fine, given the nature of remotefilelog. Differential Revision: https://phab.mercurial-scm.org/D8299

tests: add test for remotefilelog interactions with hgweb It's not uncommon for hg users to rely on hgweb as a simple GUI and history browser (I do this all the time on Mercurial), but we lack any tests to ensure things keep working. At present, this merely demonstrates the "view contents of a single file" endpoint is broken. I'll fix that in a subsequent change. Differential Revision: https://phab.mercurial-scm.org/D8298