Wed, 05 Sep 2018 21:32:45 +0900 manifest: rewrite pathlen() to not cross entry boundary stable
Yuya Nishihara <yuya@tcha.org> [Wed, 05 Sep 2018 21:32:45 +0900] rev 38802
manifest: rewrite pathlen() to not cross entry boundary Even though the entire manifest data should be terminated by '\0', it seems not nice to scan '\0' over the entry terminator, '\n'.
Wed, 26 Sep 2018 21:24:14 +0900 chgserver: do not send system() back to client if stdio redirected (issue5992) stable
Yuya Nishihara <yuya@tcha.org> [Wed, 26 Sep 2018 21:24:14 +0900] rev 38801
chgserver: do not send system() back to client if stdio redirected (issue5992) As the chg client doesn't know server-side stdio redirection, the server shouldn't upcall on "runsystem" request if the stdio streams are redirected. This patch teaches ui to remember the redirection flag, which is updated by the caller right now. Future patches (for default) will add ui methods to manage this flag internally.
Wed, 26 Sep 2018 21:21:05 +0900 chgserver: update comment describing when to fall back to core _runsystem() stable
Yuya Nishihara <yuya@tcha.org> [Wed, 26 Sep 2018 21:21:05 +0900] rev 38800
chgserver: update comment describing when to fall back to core _runsystem() The condition "output needs to be captured" was moved to the core ui, and removed at fbce78c58f1e "chg: refactor ui.system() to be partly overridden." The next patch will add one more "if" to address the issue 5992.
Wed, 26 Sep 2018 20:53:59 +0900 procutil: compare fd number to see if stdio protection is needed (issue5992) stable
Yuya Nishihara <yuya@tcha.org> [Wed, 26 Sep 2018 20:53:59 +0900] rev 38799
procutil: compare fd number to see if stdio protection is needed (issue5992) When I wrote this function for commandserver at 69f86b937035, testing object identity was suffice, and I was sloppy enough not to compare fileno() values. However, it doesn't work in chg session because chgserver reopens stdio to apply new buffering mode. This patch partially fixes the issue 5992. Still we have another problem in chgui._runsystem().
Tue, 25 Sep 2018 23:06:02 +0900 test-ssh: show that stdio redirection doesn't work with chg stable
Yuya Nishihara <yuya@tcha.org> [Tue, 25 Sep 2018 23:06:02 +0900] rev 38798
test-ssh: show that stdio redirection doesn't work with chg Running tests with --chg doesn't mean all hg invocations are replaced by chg. This patch explicitly adds the test for "chg serve --stdio", which does weird stdio dance.
Tue, 25 Sep 2018 16:32:38 -0400 revset: make heads(commonancestors(x + x^)) be x^, not x stable
Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Tue, 25 Sep 2018 16:32:38 -0400] rev 38797
revset: make heads(commonancestors(x + x^)) be x^, not x Differential Revision: https://phab.mercurial-scm.org/D4742
Tue, 25 Sep 2018 16:29:39 -0400 revset: add tests of heads(commonancestors(..)) stable
Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Tue, 25 Sep 2018 16:29:39 -0400] rev 38796
revset: add tests of heads(commonancestors(..)) The second-to-last one shows the same bug as commonancestors(..): the result should be 8, not 9. Differential Revision: https://phab.mercurial-scm.org/D4741
Tue, 25 Sep 2018 16:18:43 -0400 revset: reword commonancestor()'s help stable
Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Tue, 25 Sep 2018 16:18:43 -0400] rev 38795
revset: reword commonancestor()'s help The new version seems a bit more consistent with other doc comments, and feels clearer to me (doesn't explain "commonancestors(set)" as "common ancestors of set"). Differential Revision: https://phab.mercurial-scm.org/D4740
Tue, 25 Sep 2018 16:14:57 -0400 revset: remove part of the commonancestors() comment stable
Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Tue, 25 Sep 2018 16:14:57 -0400] rev 38794
revset: remove part of the commonancestors() comment The reason is that: - it shows up in "hg help revset", but it doesn't look like documentation targeted at users - it doesn't make sense to me: it doesn't say what happens with < 2 revisions, and is not quite right because my understanding is that this revset was created precisely because "::x and ::y" was not quite the same (when x and y don't evaluate to singletons). Differential Revision: https://phab.mercurial-scm.org/D4739
Tue, 25 Sep 2018 16:05:21 -0400 revset: make commonancestors(x + x^) be ::(x^), not ::x stable
Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Tue, 25 Sep 2018 16:05:21 -0400] rev 38793
revset: make commonancestors(x + x^) be ::(x^), not ::x Differential Revision: https://phab.mercurial-scm.org/D4738
Tue, 25 Sep 2018 15:27:41 -0400 revset: add test demonstrating a bug with commonancestor() stable
Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Tue, 25 Sep 2018 15:27:41 -0400] rev 38792
revset: add test demonstrating a bug with commonancestor() Specifically, 9 is clearly not in "::8 and ::9". Differential Revision: https://phab.mercurial-scm.org/D4737
Tue, 25 Sep 2018 16:03:14 -0400 revset: fix commonancestor test so it demonstrates correct behavior stable
Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Tue, 25 Sep 2018 16:03:14 -0400] rev 38791
revset: fix commonancestor test so it demonstrates correct behavior The problem is that hg log -r 'head()' is every changeset in the repository, because in this test repository, every changeset has a different branch. The author probably assumed all commits were on the default branch, and that they were getting topological heads, 7 and 9. As a result, this test was showing that the common ancestors of 0:9 are 0+1+2+4, which is not correct (next commit will test this). Differential Revision: https://phab.mercurial-scm.org/D4736
Tue, 11 Sep 2018 13:52:17 -0400 subrepo: mask out passwords embedded in the messages displaying a URL stable
Matt Harbison <matt_harbison@yahoo.com> [Tue, 11 Sep 2018 13:52:17 -0400] rev 38790
subrepo: mask out passwords embedded in the messages displaying a URL I noticed the password in maintenance logs for the "no changes since last push" and "pushing to" messages when pushing with an explicit path. But the test case here with :pushurl was also affected. I didn't see that cloning or pulling subrepos on demand had this problem, but it seems safer to just mask that too. There's a bit of a disconnect here, because it looks like clone is slicing off the password (makes sense not to store it in the hgrc in cleartext). But not shearing it off of an explicit path causes the subrepo not to realize that it already pushed the latest stuff. This is the easiest fix, however.
Wed, 05 Sep 2018 16:39:47 -0400 buildrpm: remove TODO that looks done to me stable
Augie Fackler <raf@durin42.com> [Wed, 05 Sep 2018 16:39:47 -0400] rev 38789
buildrpm: remove TODO that looks done to me Differential Revision: https://phab.mercurial-scm.org/D4494
Wed, 05 Sep 2018 16:29:31 -0400 buildrpm: fix embarassing bug in shell variable expansions stable
Augie Fackler <raf@durin42.com> [Wed, 05 Sep 2018 16:29:31 -0400] rev 38788
buildrpm: fix embarassing bug in shell variable expansions `$distance_$node` looks up and concatenates `$distance_` and `$node`. `$distance_` is empty, so we were getting the node without the distance. Using the curly braces makes our intent explicit and produces better-versioned RPMS. Differential Revision: https://phab.mercurial-scm.org/D4493
Wed, 05 Sep 2018 21:49:44 +0900 manifest: fix leak on error return from lazymanifest_filtercopy() stable
Yuya Nishihara <yuya@tcha.org> [Wed, 05 Sep 2018 21:49:44 +0900] rev 38787
manifest: fix leak on error return from lazymanifest_filtercopy() Spotted by ASAN. free(copy->lines) and Py_DECREF(copy->pydata) are replaced by Py_XDECREF(copy), which should call lazymanifest_dealloc(). Freeing half-initialized copy->lines is safe since copy->numlines holds a valid value.
Wed, 05 Sep 2018 21:46:53 +0900 manifest: incref/decref copy->pydata to clarify 'copy' holds a reference stable
Yuya Nishihara <yuya@tcha.org> [Wed, 05 Sep 2018 21:46:53 +0900] rev 38786
manifest: incref/decref copy->pydata to clarify 'copy' holds a reference
Wed, 05 Sep 2018 20:52:22 +0900 dirstate: use tuple interface to fix leak in pack_dirstate() stable
Yuya Nishihara <yuya@tcha.org> [Wed, 05 Sep 2018 20:52:22 +0900] rev 38785
dirstate: use tuple interface to fix leak in pack_dirstate() Spotted by ASAN. Unlike PyTuple_GET_ITEM(), PySequence_ITEM() returns a new reference. This bug could be fixed by inserting Py_CLEAR() and Py_XDECREF() appropriately, but I think requiring a tuple object is simpler and less error-prone. The cext version is jumped to 10 since 6..9 are used in the default branch. We'll need to bump it again at merge.
Wed, 05 Sep 2018 22:10:41 +0900 xdiff: fix leak in hunk_consumer() stable
Yuya Nishihara <yuya@tcha.org> [Wed, 05 Sep 2018 22:10:41 +0900] rev 38784
xdiff: fix leak in hunk_consumer() Spotted by ASAN. Since PyList_Append() does not "steal" a reference, Py_DECREF() is always required. Perhaps, this is the largest leak in this series.
Wed, 05 Sep 2018 20:57:38 +0900 base85: fix leak on error return from b85decode() stable
Yuya Nishihara <yuya@tcha.org> [Wed, 05 Sep 2018 20:57:38 +0900] rev 38783
base85: fix leak on error return from b85decode() Spotted by ASAN. We don't need to initialize 'out' to NULL, but I decided to do that for clarity.
Tue, 04 Sep 2018 11:59:12 -0400 Added signature for changeset ede3bf31fe63 stable
Augie Fackler <raf@durin42.com> [Tue, 04 Sep 2018 11:59:12 -0400] rev 38782
Added signature for changeset ede3bf31fe63
Tue, 04 Sep 2018 11:59:09 -0400 Added tag 4.7.1 for changeset ede3bf31fe63 stable
Augie Fackler <raf@durin42.com> [Tue, 04 Sep 2018 11:59:09 -0400] rev 38781
Added tag 4.7.1 for changeset ede3bf31fe63
Fri, 31 Aug 2018 21:44:24 +0900 hgweb: load revcount + 1 entries to fill nextentry in log page (issue5972) stable 4.7.1
Yuya Nishihara <yuya@tcha.org> [Fri, 31 Aug 2018 21:44:24 +0900] rev 38780
hgweb: load revcount + 1 entries to fill nextentry in log page (issue5972) "revcount + 1" is moved to the call site to make it clearer.
Fri, 24 Aug 2018 18:21:55 -0700 scmutil: avoid quadratic membership testing (issue5969) stable
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 24 Aug 2018 18:21:55 -0700] rev 38779
scmutil: avoid quadratic membership testing (issue5969) tr.changes['revs'] is an xrange, which has an O(n) __contains__ implementation. The `rev not in newrevs` lookup a few lines below will therefore be O(n^2) if all incoming changesets are public. This issue isn't present on @ because 45e05d39d9ce introduced a custom type implementing an xrange primitive with O(1) contains and switched tr.changes['revs'] to be an instance of that type. We work around the problem on the stable branch by casting the xrange to a set. This is a bit hacky because it requires allocating memory to hold each integer in the range. But we are already holding the full set of pulled revision numbers in memory multiple times (such as in `tr.changes['phases']`). So this is a relatively minor problem. This issue has been present since the phases reporting code was introduced in the 4.7 cycle by eb9835014d20. This change should be reverted/ignored when stable is merged into default. On the mozilla-unified repository with 483492 changesets, `hg clone` time improves substantially: before: 1843.700s user; 29.810s sys after: 461.170s user; 29.360s sys
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -24 +24 +50 +100 +300 +1000 +3000 +10000 tip