phabricator: use exthelper to register commands, config, and templates Differential Revision: https://phab.mercurial-scm.org/D6875

merge: check argument value with if/raise instead of an assert This shouldn't make any difference for legal code, but it'll prevent the assertion from being optimized out if someone decides to do -O on our code. Differential Revision: https://phab.mercurial-scm.org/D6879

hg: have `updatetotally` more thoroughly check updatecheck argument (API) .. api:: `mercurial.hg.updatetotally` is now more thorough about checking its `updatecheck` keyword argument. Previously invalid values would have used the configured default updatecheck method, but now will raise ValueError. Differential Revision: https://phab.mercurial-scm.org/D6878

merge: replace magic strings with NAMED_CONSTANTS (API) .. api:: `mercurial.hg.update*` and `mercurial.merge.update` now expect a value from a set of NAMED_CONSTANTS (`merge.UPDATECHECK_*` constants) rather than a collection of magic strings. As of now, the values are the same, but code should be prepared for these values to change in the future. Differential Revision: https://phab.mercurial-scm.org/D6877

singlehead: introduce special handling of closed heads Until now, the experimental option `single-head-per-branch` was also refusing closed heads. The logic is now ignoring them by default and a suboption have been added to refuse them too `single-head-per-branch:account-closed-heads`.

testlib: allow more argument to mkcommit This is simple and handy. See next changesets for usage.

singlehead: fix a small typo in a test comment The sentence is now correct.

examples: add sample fix integration for `rustfmt` Differential Revision: https://phab.mercurial-scm.org/D6873

contrib: add new examples area and start it out with a config for `hg fix` This is the configuration contributors should use for our C/C++ code. I expect to expand this file as we get more automated formatter oversight. Differential Revision: https://phab.mercurial-scm.org/D6872

tests: recognize DNS timeouts as well Differential Revision: https://phab.mercurial-scm.org/D6870

transaction: detect an attempt to truncate-to-extend on playback, raise error On some networked filesystems, writes can have delayed finalization/confirmation and write races can occur such that a remote modification will "win" and modifications will be lost. There is no functionality for providing this feedback to userspace programs (in fact, there's not even functionality for providing this information to the Linux kernel...), so these programs may see the files suddenly change. We've noticed that there have been cases where Mercurial has detected something has gone wrong and attempts to abort (rolling back the transaction), which is good. However, when rolling back the transaction, for the append-only files, we attempt to "truncate" the file back to the size it was in before the hg transaction started, but end up *extending* it. This may be harmless, but if this happens to the 00changelog.i file, we get a bunch of nulls on the end of the file and this causes hg to become *really* confused. :) If we detect that some modification of the file outside of this Mercurial process has caused the file to be smaller than the size we are attempting to truncate to, let's just exit and stop trying to clean up the repository - continuing will likely just cause more damage. Differential Revision: https://phab.mercurial-scm.org/D6867

osutil: tolerate Py_GetArgcArgv not being set up properly Differential Revision: https://phab.mercurial-scm.org/D6866

osutil: allow disabling setprocname via a define passed to the compiler In some situations, we run a custom python launcher that appears to not set up Py_GetArgcArgv correctly. We then proceed to promptly crash when we attempt to dereference NULL. Being able to completely disable setprocname is beneficial in these situations, since we won't even attempt to use it, even if the case that causes the crash is fixed. Right now, if I compile osutil.so with -DSETPROCNAME_USE_NONE, the compilation fails on python3 due to SETPROCNAME_USE_NONE redefinition. I could possibly work around that, but it's likely helpful to have a way of disabling this completely without it being brittle (i.e. if python3 ever gains the ability to perform this operation). Differential Revision: https://phab.mercurial-scm.org/D6865

stack: use repo.revs() instead of revsetlang.formatspec() + scmutil.revrange() Using scmutil.revrange() it's possible to use multiple revsets at the same time, but we're not using that functionality in stack. I thought maybe that function could be used to make stack definition customizable (by combining various parts into one set), but scmutil.revrange() gives the union of all provided revsets, which is not very useful in stack's case (we want "and" between parts, not "or").

merge with stable

merge: back out changeset a4ca0610c754 (parents order when grafting a merge) Turns out it's not enough to just swap parents, because when we do, there are unexpected bad side effects, such as a tracked file becoming untracked. These side effects need more code to be handled properly, but it's not written yet. Let's back this feature out from stable for now and some day implement it on default instead.

rust-hgpath: replace all paths and filenames with HgPath/HgPathBuf Differential Revision: https://phab.mercurial-scm.org/D6774

rust-hgpath: add HgPath and HgPathBuf structs to encapsulate handling of paths This change is a direct consequence of this discussion on the mailing list: https://www.mercurial-scm.org/pipermail/mercurial-devel/2019-August/133574.html The implementations of `HgPath` and `HgPathBuf` are, for the most part, taken directly from `OsStr` and `OsString` respectively from the standard library. What this change does *not* yet do is implement the Windows MBCS to WTF8 conversion, but it lays the basis for a very flexible interface for paths. Differential Revision: https://phab.mercurial-scm.org/D6773

wireprototypes: clarify documentation of getbundle argument types It seems like it was a mix of what the Python code would see and what was sent over the wire. I've tried to clarify both the type seen in Python and how it's transmitted. Differential Revision: https://phab.mercurial-scm.org/D6871

merge with stable

merge: respect parents order when using `graft` on a merge, this time for real See a4ca0610c754. potherp1 is a boolean variable that means "pother is ctx.p1", and parents is naturally [ctx.p1, ctx.p2]. pctx is always removed from parents, so if pctx is parents[0], then we end up using parents[1] as pother. To be true to its name, potherp1 should then be True only when pctx is at parents[1].

py3: don't double-convert "opts" to bytes The "opts" are already converted to bytes at the beginning of the function. Doing it twice results in a crash, which makes test-uncommit.t fail. The extra call was added recently, in ff1ff2aae132 (uncommit: add support to modify the commit message and date, 2019-09-07). test-uncommit.t passes again after this patch. Differential Revision: https://phab.mercurial-scm.org/D6864

py3: byte-prefix sanitisation regexes in phabricator.py So it doesn't die with "TypeError: cannot use a string pattern on a bytes-like object". Differential Revision: https://phab.mercurial-scm.org/D6863

py3: pass a bytestring into querydrev instead of a string that'll TypeError This was a regression I introduced in c19d259fd6ad. When the string gets to the memoryview in _tokenize under py3 it'll die. Differential Revision: https://phab.mercurial-scm.org/D6869

py3: add test demonstrating TypeError when phabsending skips unchanged commits Skipping can currently only happen with `--no-amend`, so this isn't a usual configuration. Differential Revision: https://phab.mercurial-scm.org/D6868

tests: clean up built binaries after running test-fuzz-targets.t Most users won't notice a change here because they won't have the fuzzer infra, but by good fortune my workstation has the required bits and keeps leaving the fuzzer binaries around. Differential Revision: https://phab.mercurial-scm.org/D6862

fastannotate: remove support for flock() locking We've seen enough weirdness in CI with flock for remotefilelog that I'm now of the opinion we should just stop using flock() everywhere until someone has a concrete need for the extra performance *and* a way to only use it when safe (even if that's just default-to-off.) Differential Revision: https://phab.mercurial-scm.org/D6861

remotefilelog: remove dead code for using flock() for locking Differential Revision: https://phab.mercurial-scm.org/D6860