Tue, 17 Sep 2019 14:57:42 -0700 osutil: allow disabling setprocname via a define passed to the compiler
Kyle Lippincott <spectral@google.com> [Tue, 17 Sep 2019 14:57:42 -0700] rev 42961
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
Sun, 22 Sep 2019 14:33:56 +0700 stack: use repo.revs() instead of revsetlang.formatspec() + scmutil.revrange()
Anton Shestakov <av6@dwimlabs.net> [Sun, 22 Sep 2019 14:33:56 +0700] rev 42960
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").
Mon, 23 Sep 2019 21:29:53 +0900 merge with stable
Yuya Nishihara <yuya@tcha.org> [Mon, 23 Sep 2019 21:29:53 +0900] rev 42959
merge with stable
Fri, 20 Sep 2019 23:31:03 +0700 merge: back out changeset a4ca0610c754 (parents order when grafting a merge) stable 5.1.2
Anton Shestakov <av6@dwimlabs.net> [Fri, 20 Sep 2019 23:31:03 +0700] rev 42958
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.
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -4 +4 +10 +30 +100 +300 +1000 +3000 tip