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.
Sun, 01 Sep 2019 20:53:14 +0200 rust-hgpath: replace all paths and filenames with HgPath/HgPathBuf
Raphaël Gomès <rgomes@octobus.net> [Sun, 01 Sep 2019 20:53:14 +0200] rev 42957
rust-hgpath: replace all paths and filenames with HgPath/HgPathBuf Differential Revision: https://phab.mercurial-scm.org/D6774
Sun, 01 Sep 2019 20:53:14 +0200 rust-hgpath: add HgPath and HgPathBuf structs to encapsulate handling of paths
Raphaël Gomès <rgomes@octobus.net> [Sun, 01 Sep 2019 20:53:14 +0200] rev 42956
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
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -6 +6 +10 +30 +100 +300 +1000 +3000 tip