Sun, 15 Dec 2019 21:34:00 -0500 util: move common proxyobserver attributes to the base class
Matt Harbison <matt_harbison@yahoo.com> [Sun, 15 Dec 2019 21:34:00 -0500] rev 43926
util: move common proxyobserver attributes to the base class Fixes the following pytype warnings: line 791, in _writedata: No attribute 'logdata' on baseproxyobserver [attribute-error] line 792, in _writedata: No attribute 'logdataapis' on baseproxyobserver [attribute-error] line 793, in _writedata: No attribute 'fh' on baseproxyobserver [attribute-error] line 794, in _writedata: No attribute 'fh' on baseproxyobserver [attribute-error] line 799, in _writedata: No attribute 'logdataapis' on baseproxyobserver [attribute-error] line 800, in _writedata: No attribute 'fh' on baseproxyobserver [attribute-error] line 802, in _writedata: No attribute 'fh' on baseproxyobserver [attribute-error] line 803, in _writedata: No attribute 'name' on baseproxyobserver [attribute-error] line 805, in _writedata: No attribute 'fh' on baseproxyobserver [attribute-error] line 809, in _writedata: No attribute 'logdataapis' on baseproxyobserver [attribute-error] line 810, in _writedata: No attribute 'fh' on baseproxyobserver [attribute-error] line 814, in _writedata: No attribute 'fh' on baseproxyobserver [attribute-error] line 815, in _writedata: No attribute 'name' on baseproxyobserver [attribute-error] line 817, in _writedata: No attribute 'fh' on baseproxyobserver [attribute-error] Differential Revision: https://phab.mercurial-scm.org/D7675
Wed, 11 Dec 2019 22:23:42 -0800 config: drop debug messages saying where config was read from
Martin von Zweigbergk <martinvonz@google.com> [Wed, 11 Dec 2019 22:23:42 -0800] rev 43925
config: drop debug messages saying where config was read from `hg config --debug` includes lines like this: set config by: $EDITOR but also lines like this: $EDITOR: ui.editor=emacs -nw The `set config by` messages don't seem to provide much additional information over what we get from the `$EDITOR:`-type message. I could imagine wanting to see which values got overriden by a later entry, but that information is already not present. So let's just remove the first type of output. My next patch would otherwise amplify the redundant output (there would be one `set config by` for each line in `mergetools.rc`). Differential Revision: https://phab.mercurial-scm.org/D7627
Wed, 11 Dec 2019 11:22:37 -0800 rcutil: don't check if defaultrc/ is a directory -- we know it is
Martin von Zweigbergk <martinvonz@google.com> [Wed, 11 Dec 2019 11:22:37 -0800] rev 43924
rcutil: don't check if defaultrc/ is a directory -- we know it is `mercurial/defaultrc/` is a directory both in the Mercurial repo and once installed on a target platform. The directory was created in c4ce077588d0 (config: introduce "built-in" default configuration settings in default.d, 2014-09-04). That commit has some more information, but it still doesn't seem to say that `defaultrc/` (then called `default.d/`) could be a file. Perhaps the check was there to allow you to run the same code on an older install/repo? Differential Revision: https://phab.mercurial-scm.org/D7624
Fri, 29 Nov 2019 17:30:57 +0100 rust-matchers: add support for `exactmatcher` in `dirstate.status`
Raphaël Gomès <rgomes@octobus.net> [Fri, 29 Nov 2019 17:30:57 +0100] rev 43923
rust-matchers: add support for `exactmatcher` in `dirstate.status` `exactmatcher` is the name in the Python implementation and corresponds to `FileMatcher` in Rust. Differential Revision: https://phab.mercurial-scm.org/D7531
Fri, 29 Nov 2019 17:30:10 +0100 rust-dirstate-status: update bridge for new rust version of `dirstate.status`
Raphaël Gomès <rgomes@octobus.net> [Fri, 29 Nov 2019 17:30:10 +0100] rev 43922
rust-dirstate-status: update bridge for new rust version of `dirstate.status` Differential Revision: https://phab.mercurial-scm.org/D7530
Fri, 29 Nov 2019 17:29:06 +0100 rust-dirstate-status: add `walk_explicit` implementation, use `Matcher` trait
Raphaël Gomès <rgomes@octobus.net> [Fri, 29 Nov 2019 17:29:06 +0100] rev 43921
rust-dirstate-status: add `walk_explicit` implementation, use `Matcher` trait This is the first time we actually use the `Matcher` trait, still for a small subset of all matchers defined in Python. While I haven't yet actually measured the performance of this, I have tried to avoid any unnecessary allocations. This forces the use of heavy lifetimes annotations which I am not sure we can simplify, although I would be happy to be proven wrong. Differential Revision: https://phab.mercurial-scm.org/D7529
Fri, 29 Nov 2019 18:54:06 +0100 rust-matchers: add `FileMatcher` implementation
Raphaël Gomès <rgomes@octobus.net> [Fri, 29 Nov 2019 18:54:06 +0100] rev 43920
rust-matchers: add `FileMatcher` implementation Mercurial defines an `exactmatcher`, I find `FileMatcher` to be clearer, but am not opposed to using the old name. This change also switched the order of `assert_eq` arguments as it is clearer that way for most people. Differential Revision: https://phab.mercurial-scm.org/D7528
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -7 +7 +10 +30 +100 +300 +1000 +3000 tip