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
Wed, 18 Sep 2019 13:50:33 -0700 wireprototypes: clarify documentation of getbundle argument types
Martin von Zweigbergk <martinvonz@google.com> [Wed, 18 Sep 2019 13:50:33 -0700] rev 42955
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
Thu, 19 Sep 2019 07:50:24 +0900 merge with stable
Yuya Nishihara <yuya@tcha.org> [Thu, 19 Sep 2019 07:50:24 +0900] rev 42954
merge with stable
Wed, 18 Sep 2019 17:53:10 +0700 merge: respect parents order when using `graft` on a merge, this time for real stable
Anton Shestakov <av6@dwimlabs.net> [Wed, 18 Sep 2019 17:53:10 +0700] rev 42953
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].
Tue, 17 Sep 2019 15:35:16 -0700 py3: don't double-convert "opts" to bytes
Martin von Zweigbergk <martinvonz@google.com> [Tue, 17 Sep 2019 15:35:16 -0700] rev 42952
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
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 tip