cb372d09d30a94f220624fe64c5a0dfd20733305: merge with stable
Augie Fackler <augie@google.com> - Tue, 04 Dec 2018 17:13:01 -0500 - rev 53585
Push 1079 by gszorc@mozilla.com at Mon, 10 Dec 2018 19:44:59 +0000
merge with stable
47719d7c581f18c1e6c98b05e2f79307c2ea50bd: Added signature for changeset 1c8c54cf9725 stable
Augie Fackler <raf@durin42.com> - Tue, 04 Dec 2018 17:04:19 -0500 - rev 53584
Push 1079 by gszorc@mozilla.com at Mon, 10 Dec 2018 19:44:59 +0000
Added signature for changeset 1c8c54cf9725
ee948f23bf2e73701c82deafce27197f99be5aac: Added tag 4.8.1 for changeset 1c8c54cf9725 stable
Augie Fackler <raf@durin42.com> - Tue, 04 Dec 2018 17:04:17 -0500 - rev 53583
Push 1079 by gszorc@mozilla.com at Mon, 10 Dec 2018 19:44:59 +0000
Added tag 4.8.1 for changeset 1c8c54cf9725
1c8c54cf97256f4468da2eb4dbee24f7f3888e71: rebase: fix path auditing to audit path relative to repo root (issue5818) stable 4.8.1
Martin von Zweigbergk <martinvonz@google.com> - Tue, 20 Nov 2018 14:43:27 -0800 - rev 53582
Push 1079 by gszorc@mozilla.com at Mon, 10 Dec 2018 19:44:59 +0000
rebase: fix path auditing to audit path relative to repo root (issue5818) Before this patch, when rebasing a file called "foo/bar", we would check e.g. if "/foo" (i.e. rooted at the file system root) was a symlink. Differential Revision: https://phab.mercurial-scm.org/D5361
d10b1dc134316c13c637232fc52389aa24319e12: tests: show bad path auditing in in-memory rebase stable
Martin von Zweigbergk <martinvonz@google.com> - Tue, 04 Dec 2018 08:56:43 -0800 - rev 53581
Push 1079 by gszorc@mozilla.com at Mon, 10 Dec 2018 19:44:59 +0000
tests: show bad path auditing in in-memory rebase Thanks to Yuya for providing this test case in https://bz.mercurial-scm.org/show_bug.cgi?id=5818. Differential Revision: https://phab.mercurial-scm.org/D5368
9b1d5eea07f9be73df44f70a65cbc511f8063f81: tests: add a missing "cd .." to test-rebase-inmemory.t stable
Martin von Zweigbergk <martinvonz@google.com> - Tue, 04 Dec 2018 08:55:48 -0800 - rev 53580
Push 1079 by gszorc@mozilla.com at Mon, 10 Dec 2018 19:44:59 +0000
tests: add a missing "cd .." to test-rebase-inmemory.t Differential Revision: https://phab.mercurial-scm.org/D5367
884321cd26c30d4ea7a693b467c41270e612cde8: rust: fix possible out-of-bounds read through index_get_parents() stable
Yuya Nishihara <yuya@tcha.org> - Sun, 28 Oct 2018 21:29:04 +0900 - rev 53579
Push 1079 by gszorc@mozilla.com at Mon, 10 Dec 2018 19:44:59 +0000
rust: fix possible out-of-bounds read through index_get_parents() index_get_parents() is an internal function, which doesn't check if the specified rev is valid. If rustlazyancestors() were instantiated with an invalid stoprev, it would access to invalid memory region. This is NOT a security fix as there's no Python code triggering the bug, but included in this series to not give a notion about the memory issue fixed by the previous patch.
9cdd525d97b24812f525056d831ce456c8ba714a: revlog: fix out-of-bounds access by negative parents read from revlog (SEC) stable
Yuya Nishihara <yuya@tcha.org> - Thu, 01 Nov 2018 20:32:59 +0900 - rev 53578
Push 1079 by gszorc@mozilla.com at Mon, 10 Dec 2018 19:44:59 +0000
revlog: fix out-of-bounds access by negative parents read from revlog (SEC) 82d6a35cf432 wasn't enough. Several callers don't check negative revisions but for -1 (nullrev), which would directly lead to out-of-bounds read, and buffer overflow could follow. RCE might be doable with carefully crafted revlog structure, though I don't think this would be useful attack surface.
e13ab4acf555daf8fac593127b6a076288551710: rust: peek_mut optim for lazy ancestors
Georges Racinet <gracinet@anybox.fr> - Thu, 29 Nov 2018 09:13:13 +0000 - rev 53568
Push 1078 by gszorc@mozilla.com at Tue, 04 Dec 2018 20:59:11 +0000
rust: peek_mut optim for lazy ancestors This is one of the two optimizations that are also present in the Python code: replacing pairs of pop/push on the BinaryHeap by single updates, hence having it under the hood maintain its consistency (sift) only once. On Mozilla central, the measured gain (see details below) is around 7%. Creating the PeekMut object by calling peek_mut() right away instead of peek() first is less efficient (gain is only 4%, stats not included). Our interpretation is that its creation has a cost which is vasted in the cases where it ends by droping the value (Peekmut::pop() just does self.heap.pop() anyway). On the other hand, the immutable peek() is very fast: it's just taking a reference in the underlying vector. The Python version still has another optimization: if parent(current) == current-1, then the heap doesn't need to maintain its consistency, since we already know that it's bigger than all the others in the heap. Rust's BinaryHeap doesn't allow us to mutate its biggest element with no housekeeping, but we tried it anyway, with a copy of the BinaryHeap implementation with a dedicaded added method: it's not worth the technical debt in our opinion (we measured only a further 1.6% improvement). One possible explanation would be that the sift is really fast anyway in that case, whereas it's not in the case of Python, because it's at least partly done in slow Python code. Still it's possible that replacing BinaryHeap by something more dedicated to discrete ordered types could be faster. Measurements on mozilla-central: Three runs of 'hg perfancestors' on the parent changeset: Moyenne des m├ędianes: 0.100587 ! wall 0.100062 comb 0.100000 user 0.100000 sys 0.000000 (best of 98) ! wall 0.135804 comb 0.130000 user 0.130000 sys 0.000000 (max of 98) ! wall 0.102864 comb 0.102755 user 0.099286 sys 0.003469 (avg of 98) ! wall 0.101486 comb 0.110000 user 0.110000 sys 0.000000 (median of 98) ! wall 0.096804 comb 0.090000 user 0.090000 sys 0.000000 (best of 100) ! wall 0.132235 comb 0.130000 user 0.120000 sys 0.010000 (max of 100) ! wall 0.100258 comb 0.100300 user 0.096000 sys 0.004300 (avg of 100) ! wall 0.098384 comb 0.100000 user 0.100000 sys 0.000000 (median of 100) ! wall 0.099925 comb 0.100000 user 0.100000 sys 0.000000 (best of 98) ! wall 0.133518 comb 0.140000 user 0.130000 sys 0.010000 (max of 98) ! wall 0.102381 comb 0.102449 user 0.098265 sys 0.004184 (avg of 98) ! wall 0.101891 comb 0.090000 user 0.090000 sys 0.000000 (median of 98) Mean of the medians: 0.100587 On the present changeset: ! wall 0.091344 comb 0.090000 user 0.090000 sys 0.000000 (best of 100) ! wall 0.122728 comb 0.120000 user 0.110000 sys 0.010000 (max of 100) ! wall 0.093268 comb 0.093300 user 0.089300 sys 0.004000 (avg of 100) ! wall 0.092567 comb 0.100000 user 0.090000 sys 0.010000 (median of 100) ! wall 0.093294 comb 0.080000 user 0.080000 sys 0.000000 (best of 100) ! wall 0.144887 comb 0.150000 user 0.140000 sys 0.010000 (max of 100) ! wall 0.097708 comb 0.097700 user 0.093400 sys 0.004300 (avg of 100) ! wall 0.094980 comb 0.100000 user 0.090000 sys 0.010000 (median of 100) ! wall 0.091262 comb 0.090000 user 0.080000 sys 0.010000 (best of 100) ! wall 0.123772 comb 0.130000 user 0.120000 sys 0.010000 (max of 100) ! wall 0.093188 comb 0.093200 user 0.089300 sys 0.003900 (avg of 100) ! wall 0.092364 comb 0.100000 user 0.090000 sys 0.010000 (median of 100) Mean of the medians is 0.0933 Differential Revision: https://phab.mercurial-scm.org/D5358
0fecf70fa8d47c73765d8ba9d0ae1edc63f7373f: fuzz: grep away HAVE_GETC_UNLOCKED in pyconfig.h to avoid msan badness
Augie Fackler <augie@google.com> - Mon, 03 Dec 2018 18:07:09 -0500 - rev 53567
Push 1078 by gszorc@mozilla.com at Tue, 04 Dec 2018 20:59:11 +0000
fuzz: grep away HAVE_GETC_UNLOCKED in pyconfig.h to avoid msan badness Per discussion with Greg Smith and the patches on https://bugs.python.org/issue35214. This, combined with the previous patch, fixes msan builds on oss-fuzz. Differential Revision: https://phab.mercurial-scm.org/D5363
177b47ce03754a11f1f810e16f85af2f6a478b1a: fuzz: more correctly specify CFLAGS and LDFLAGS when building Python
Augie Fackler <augie@google.com> - Tue, 13 Nov 2018 09:19:05 -0500 - rev 53566
Push 1078 by gszorc@mozilla.com at Tue, 04 Dec 2018 20:59:11 +0000
fuzz: more correctly specify CFLAGS and LDFLAGS when building Python Gets us closer to a working msan build alongside our asan build. Differential Revision: https://phab.mercurial-scm.org/D5362
c460b1643eb091e944ae400908a432a02837e54d: tests: stabilize test-blackbox.t on Windows
Matt Harbison <matt_harbison@yahoo.com> - Tue, 04 Dec 2018 00:19:33 -0500 - rev 53565
Push 1078 by gszorc@mozilla.com at Tue, 04 Dec 2018 20:59:11 +0000
tests: stabilize test-blackbox.t on Windows I didn't look into why the error is more detailed, but that seems like it's a good thing (other than for recording tests).
f6d37e84d8f99d7d06c4a7391e7505e050258b74: tests: stabilize for recent wcache changes
Matt Harbison <matt_harbison@yahoo.com> - Tue, 04 Dec 2018 00:16:12 -0500 - rev 53564
Push 1078 by gszorc@mozilla.com at Tue, 04 Dec 2018 20:59:11 +0000
tests: stabilize for recent wcache changes This goes with 47e3f554df35::d5622dfe4ba3. I'm not sure if it was really expected that there would be no wcache directory if neither execbit nor symlink is supported.
151aec6494a8c8566e098443189dd4d17c56b575: extdiff: avoid double backslashes in the displayed tool path on Windows
Matt Harbison <matt_harbison@yahoo.com> - Mon, 03 Dec 2018 12:48:42 -0500 - rev 53563
Push 1078 by gszorc@mozilla.com at Tue, 04 Dec 2018 20:59:11 +0000
extdiff: avoid double backslashes in the displayed tool path on Windows This shows the tool path in the help, and changed in 67b180c0e263. uirepr() already does the same thing, but that undoes the mangling in its call to repr().
01c335afc997e79d674fad0bbe623ffac6472722: contrib: add a helper script that help to build interesting repositories
Boris Feld <boris.feld@octobus.net> - Wed, 28 Nov 2018 05:06:58 +0100 - rev 53562
Push 1078 by gszorc@mozilla.com at Tue, 04 Dec 2018 20:59:11 +0000
contrib: add a helper script that help to build interesting repositories The script is dedicated to building a couple of repositories that should be interesting to run discovery from one another. It seems a common enough need to contribute it upstream.
bad0053efaf6c9bdc9b6bd613dcfb2e95d36ec99: py3: listify filter() to call len() on it
Pulkit Goyal <pulkit@yandex-team.ru> - Mon, 03 Dec 2018 19:42:46 +0300 - rev 53561
Push 1078 by gszorc@mozilla.com at Tue, 04 Dec 2018 20:59:11 +0000
py3: listify filter() to call len() on it Differential Revision: https://phab.mercurial-scm.org/D5354
44c2e80db98532eea9ee3f3ec226e199e1e8a72e: rebase: fix dir/file conflict detection when using in-mem merge stable
Martin von Zweigbergk <martinvonz@google.com> - Mon, 03 Dec 2018 11:14:44 -0800 - rev 53560
Push 1078 by gszorc@mozilla.com at Tue, 04 Dec 2018 20:59:11 +0000
rebase: fix dir/file conflict detection when using in-mem merge Differential Revision: https://phab.mercurial-scm.org/D5360
e204d9a2752876b313c66ef1c3387050c70cdc97: tests: show that in-mem rebase does not find path dir/file conflicts stable
Martin von Zweigbergk <martinvonz@google.com> - Mon, 03 Dec 2018 11:11:34 -0800 - rev 53559
Push 1078 by gszorc@mozilla.com at Tue, 04 Dec 2018 20:59:11 +0000
tests: show that in-mem rebase does not find path dir/file conflicts Differential Revision: https://phab.mercurial-scm.org/D5359
97190b0bb81a80fa3ca3aac641940fc1e4f14aab: extdiff: register the configuration generated commands with a help category stable
Matt Harbison <matt_harbison@yahoo.com> - Mon, 03 Dec 2018 20:59:48 -0500 - rev 53558
Push 1078 by gszorc@mozilla.com at Tue, 04 Dec 2018 20:59:11 +0000
extdiff: register the configuration generated commands with a help category Otherwise, 'extdiff' shows up under file management and the rest of the commands are at the bottom under 'Uncategorized'.
6f679f25fd4d5a3e209a45058fc60ed294fdab59: rebase: abort in-mem rebase if there's a dirty merge state stable
Martin von Zweigbergk <martinvonz@google.com> - Mon, 03 Dec 2018 09:36:40 -0800 - rev 53557
Push 1078 by gszorc@mozilla.com at Tue, 04 Dec 2018 20:59:11 +0000
rebase: abort in-mem rebase if there's a dirty merge state In-memory merge uses the on-disk merge state, so we should not allow it run in-memory merge when the merge state is not clean. We should probably not use the on-disk merge state when running in-memory merge, but chaning that is not suitable for the stable branch. Differential Revision: https://phab.mercurial-scm.org/D5357
(0) -30000 -10000 -1000 -300 -100 -50 -20 +20 +50 +100 tip