Martin von Zweigbergk <martinvonz@google.com> [Wed, 25 Sep 2019 14:35:08 -0700] rev 42981
update: clarify calculateupdate() call sites by specifying argument names
merge.calculateupdate() takes a lot of parameters and I get confused
all the time which is which.
See also b14fdf1fb615 (update: clarify update() call sites by
specifying argument names, 2017-02-09).
Differential Revision: https://phab.mercurial-scm.org/D6883
Augie Fackler <augie@google.com> [Wed, 25 Sep 2019 17:57:16 -0400] rev 42980
bookmarks: remove changectx() method from bmstore (API)
All the callsites of this method have access to the repo, and I'd
rather not have to duplicate this across alternative bmstore
implementations. Besides, it feels like a bit of a layering violation.
.. api::
`mercurial.bookmarks.bmstore` no longer has a convenience method
for looking up changectx instances from a bookmark name. Use
`repo[repo.bookmarks[name]]` intead of
`repo.bookmarks.changectx(name)`.
Differential Revision: https://phab.mercurial-scm.org/D6884
Augie Fackler <augie@google.com> [Wed, 25 Sep 2019 13:50:48 -0400] rev 42979
histedit: sniff-test for untracked file conflicts before prompting for rules
This bug is as old as histedit, which is more than 10 years! I'm a
little sad about the extra calculations here that we're just going to
throw out, but I don't see any better way to look for untracked file
conflicts and I want the bug fixed.
Differential Revision: https://phab.mercurial-scm.org/D6882
Augie Fackler <augie@google.com> [Mon, 23 Sep 2019 16:29:16 -0400] rev 42978
histedit: demonstrate breakage when `update` to a revision breaks
I'm honestly impressed that nobody has hit this in the over a decade
that histedit has existed, but here we are.
Differential Revision: https://phab.mercurial-scm.org/D6881
Paul Gossman <pgossman@janestreet.com> [Wed, 25 Sep 2019 10:59:29 -0400] rev 42977
rebase: track new nodes when --keep is set
When --keep is passed with rebase, the new nodes created are not
accessible from templates.
This change enables accessing the newly-created nodes from nodechanges,
just as if --keep was not set.
Differential Revision: https://phab.mercurial-scm.org/D6880
Matt Harbison <matt_harbison@yahoo.com> [Sat, 21 Sep 2019 13:42:23 -0400] rev 42976
uncommit: fix typo in help text
Differential Revision: https://phab.mercurial-scm.org/D6874
Matt Harbison <matt_harbison@yahoo.com> [Tue, 24 Sep 2019 22:41:07 -0400] rev 42975
phabricator: use exthelper to register commands, config, and templates
Differential Revision: https://phab.mercurial-scm.org/D6875
Augie Fackler <augie@google.com> [Wed, 25 Sep 2019 11:04:08 -0400] rev 42974
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
Augie Fackler <augie@google.com> [Wed, 25 Sep 2019 11:02:32 -0400] rev 42973
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
Augie Fackler <augie@google.com> [Wed, 25 Sep 2019 10:53:10 -0400] rev 42972
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
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 25 Sep 2019 12:59:26 +0200] rev 42971
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`.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 25 Sep 2019 12:57:11 +0200] rev 42970
testlib: allow more argument to mkcommit
This is simple and handy. See next changesets for usage.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 25 Sep 2019 12:35:34 +0200] rev 42969
singlehead: fix a small typo in a test comment
The sentence is now correct.
Augie Fackler <augie@google.com> [Mon, 20 May 2019 14:37:38 -0400] rev 42968
examples: add sample fix integration for `rustfmt`
Differential Revision: https://phab.mercurial-scm.org/D6873
Augie Fackler <augie@google.com> [Mon, 20 May 2019 14:33:46 -0400] rev 42967
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
Joerg Sonnenberger <joerg@bec.de> [Wed, 18 Sep 2019 06:04:59 +0200] rev 42966
tests: recognize DNS timeouts as well
Differential Revision: https://phab.mercurial-scm.org/D6870
Kyle Lippincott <spectral@google.com> [Tue, 17 Sep 2019 14:01:26 -0700] rev 42965
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
Kyle Lippincott <spectral@google.com> [Tue, 17 Sep 2019 15:09:25 -0700] rev 42964
osutil: tolerate Py_GetArgcArgv not being set up properly
Differential Revision: https://phab.mercurial-scm.org/D6866
Kyle Lippincott <spectral@google.com> [Tue, 17 Sep 2019 14:57:42 -0700] rev 42963
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
Anton Shestakov <av6@dwimlabs.net> [Sun, 22 Sep 2019 14:33:56 +0700] rev 42962
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").
Yuya Nishihara <yuya@tcha.org> [Mon, 23 Sep 2019 21:29:53 +0900] rev 42961
merge with stable
Raphaël Gomès <rgomes@octobus.net> [Sun, 01 Sep 2019 20:53:14 +0200] rev 42960
rust-hgpath: replace all paths and filenames with HgPath/HgPathBuf
Differential Revision: https://phab.mercurial-scm.org/D6774
Raphaël Gomès <rgomes@octobus.net> [Sun, 01 Sep 2019 20:53:14 +0200] rev 42959
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
Martin von Zweigbergk <martinvonz@google.com> [Wed, 18 Sep 2019 13:50:33 -0700] rev 42958
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
Yuya Nishihara <yuya@tcha.org> [Thu, 19 Sep 2019 07:50:24 +0900] rev 42957
merge with stable
Martin von Zweigbergk <martinvonz@google.com> [Tue, 17 Sep 2019 15:35:16 -0700] rev 42956
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
Ian Moody <moz-ian@perix.co.uk> [Tue, 17 Sep 2019 21:06:07 +0100] rev 42955
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
Ian Moody <moz-ian@perix.co.uk> [Wed, 18 Sep 2019 00:20:43 +0100] rev 42954
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
Ian Moody <moz-ian@perix.co.uk> [Wed, 18 Sep 2019 00:05:52 +0100] rev 42953
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
Augie Fackler <augie@google.com> [Tue, 17 Sep 2019 15:07:08 -0400] rev 42952
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
Augie Fackler <augie@google.com> [Tue, 17 Sep 2019 14:22:22 -0400] rev 42951
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
Augie Fackler <augie@google.com> [Tue, 17 Sep 2019 14:20:13 -0400] rev 42950
remotefilelog: remove dead code for using flock() for locking
Differential Revision: https://phab.mercurial-scm.org/D6860