Mon, 14 Oct 2019 12:54:49 -0400 black: use multiline exclude definition
Augie Fackler <augie@google.com> [Mon, 14 Oct 2019 12:54:49 -0400] rev 43224
black: use multiline exclude definition Our excludes list is pretty complicated, so let's give ourselves some readability. Black treats multiline exclude definitions as verbse regular expressions, so we can split this up and make it easier to consume. Differential Revision: https://phab.mercurial-scm.org/D7089
Mon, 14 Oct 2019 12:52:33 -0400 black: move remaining config knobs into toml file
Augie Fackler <augie@google.com> [Mon, 14 Oct 2019 12:52:33 -0400] rev 43223
black: move remaining config knobs into toml file Differential Revision: https://phab.mercurial-scm.org/D7088
Mon, 14 Oct 2019 12:46:32 -0400 black: rename pyproject.toml to black.toml
Augie Fackler <augie@google.com> [Mon, 14 Oct 2019 12:46:32 -0400] rev 43222
black: rename pyproject.toml to black.toml Black won't read this automatically (you'll have to specify --config), but having a pyproject.toml *at all* puts pip in PEP 517/518 mode which breaks us for obscure reasons I don't understand. Rather than waste a ton of time fighting with pip, let's just do this. Differential Revision: https://phab.mercurial-scm.org/D7087
Sat, 12 Oct 2019 15:12:54 -0700 fix: remove a never-true check for unset pattern in Fixer.affects()
Martin von Zweigbergk <martinvonz@google.com> [Sat, 12 Oct 2019 15:12:54 -0700] rev 43221
fix: remove a never-true check for unset pattern in Fixer.affects() We don't create an instance of a Fixer if the pattern is None, so we don't need to check that in affects(). Differential Revision: https://phab.mercurial-scm.org/D7086
Fri, 26 Jul 2019 08:43:57 -0700 fix: warn when a fixer doesn't have a configured command
Martin von Zweigbergk <martinvonz@google.com> [Fri, 26 Jul 2019 08:43:57 -0700] rev 43220
fix: warn when a fixer doesn't have a configured command It seems we currently produce an empty command line and then decide to not run it, but it seems better to skip that part too. Differential Revision: https://phab.mercurial-scm.org/D7085
Sat, 12 Oct 2019 11:00:20 -0700 fix: make Fixer initialization more explicit for clarity
Martin von Zweigbergk <martinvonz@google.com> [Sat, 12 Oct 2019 11:00:20 -0700] rev 43219
fix: make Fixer initialization more explicit for clarity I found it quite confusing that Fixer accessed fields that seemed like they didn't exist. Differential Revision: https://phab.mercurial-scm.org/D7084
Sat, 12 Oct 2019 11:16:19 -0700 fix: don't pass in default value when looking up config
Martin von Zweigbergk <martinvonz@google.com> [Sat, 12 Oct 2019 11:16:19 -0700] rev 43218
fix: don't pass in default value when looking up config The defaults are now registered correctly so we don't need to pass in the default value when we look up a config value. Differential Revision: https://phab.mercurial-scm.org/D7083
Sat, 12 Oct 2019 11:13:55 -0700 fix: fix registration of config item defaults
Martin von Zweigbergk <martinvonz@google.com> [Sat, 12 Oct 2019 11:13:55 -0700] rev 43217
fix: fix registration of config item defaults Before this patch, because of the "(:<name>)?", all registered patterns would match and the default value would not be the one we thought we had registered (maybe it just took the default value for the first match?). This didn't matter because we didn't care about the default value; we used our own, intended default value in getfixers() anyway. We also have to look up each config item individually in order to not get developer warnings. Differential Revision: https://phab.mercurial-scm.org/D7082
Sat, 12 Oct 2019 12:41:53 -0700 automation: capture additional exception when formatting
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 12 Oct 2019 12:41:53 -0700] rev 43216
automation: capture additional exception when formatting I started encountering this for some reason. Differential Revision: https://phab.mercurial-scm.org/D7078
Sat, 12 Oct 2019 11:36:26 -0700 contrib: update to latest Windows package versions
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 12 Oct 2019 11:36:26 -0700] rev 43215
contrib: update to latest Windows package versions Let's keep modern. Differential Revision: https://phab.mercurial-scm.org/D7077
Sun, 13 Oct 2019 21:47:05 +0900 rust-cpython: drop direct dependency on python(27|3)_sys
Yuya Nishihara <yuya@tcha.org> [Sun, 13 Oct 2019 21:47:05 +0900] rev 43214
rust-cpython: drop direct dependency on python(27|3)_sys We no longer use it.
Sun, 13 Oct 2019 17:07:44 +0900 rust-cpython: leverage upstreamed py_capsule_fn!() macro
Yuya Nishihara <yuya@tcha.org> [Sun, 13 Oct 2019 17:07:44 +0900] rev 43213
rust-cpython: leverage upstreamed py_capsule_fn!() macro
Sun, 13 Oct 2019 17:05:09 +0900 rust-cpython: bump cpython crates to 0.3
Yuya Nishihara <yuya@tcha.org> [Sun, 13 Oct 2019 17:05:09 +0900] rev 43212
rust-cpython: bump cpython crates to 0.3 Unblocks py_capsule_fn!().
Sun, 13 Oct 2019 17:02:26 +0900 rust-cpython: turn inline comments into non-doc comments
Yuya Nishihara <yuya@tcha.org> [Sun, 13 Oct 2019 17:02:26 +0900] rev 43211
rust-cpython: turn inline comments into non-doc comments
Sun, 13 Oct 2019 17:01:10 +0900 rust-cpython: fix signature of make_dirstate_tuple()
Yuya Nishihara <yuya@tcha.org> [Sun, 13 Oct 2019 17:01:10 +0900] rev 43210
rust-cpython: fix signature of make_dirstate_tuple() Fortunately, the layout of PyObject {} is compatible with a C pointer, but we shouldn't rely on that. This also fixes the handling of NULL pointer.
Sun, 13 Oct 2019 16:58:15 +0900 rust-cpython: mark capsule function as unsafe
Yuya Nishihara <yuya@tcha.org> [Sun, 13 Oct 2019 16:58:15 +0900] rev 43209
rust-cpython: mark capsule function as unsafe
Sun, 13 Oct 2019 16:55:17 +0900 rust-cpython: add wrapper around decapsule_make_dirstate_tuple()
Yuya Nishihara <yuya@tcha.org> [Sun, 13 Oct 2019 16:55:17 +0900] rev 43208
rust-cpython: add wrapper around decapsule_make_dirstate_tuple() There are a couple of safety issues. First, the returned function pointer must be unsafe. Second, its return value must be a raw pointer (i.e. python27_sys::PyObject), not a cpython::PyObject. The wrapper function will address these issues.
Sun, 13 Oct 2019 02:10:26 +0200 eol: don't fallback to use .hgeol from tip (BC)
Mads Kiilerich <mads@kiilerich.com> [Sun, 13 Oct 2019 02:10:26 +0200] rev 43207
eol: don't fallback to use .hgeol from tip (BC) If no .hgeol were found in the current working directory, eol would fallback to use the one in tip. That could in some cases give very confusing or wrong behaviour when it applied wrong filters. It might be convenient to have plain 'clone' immediately apply 'native' encoding patterns in the cloned repo. But it is wrong to assume that this revision is tip, and even more wrong to also apply it when not cloning - for example when updating between history revisions. The encoding should always match the content of the current .hgeol . It should never use anything else.
Mon, 14 Oct 2019 01:42:24 +0200 eol: tweak test-eol-clone.t with better descriptions and logging
Mads Kiilerich <mads@kiilerich.com> [Mon, 14 Oct 2019 01:42:24 +0200] rev 43206
eol: tweak test-eol-clone.t with better descriptions and logging Expose impact of changes coming next ...
Sun, 13 Oct 2019 02:15:07 +0200 eol: fix update - don't use and apply removed .hgeol patterns
Mads Kiilerich <mads@kiilerich.com> [Sun, 13 Oct 2019 02:15:07 +0200] rev 43205
eol: fix update - don't use and apply removed .hgeol patterns 'hg up -C' to revisions with different .hgeol patterns could leave dirty changes in the working directory. That could make deployment of new .hgeol filters tricky: they would "occasionally" apply also in branches where they shouldn't. Fixed by dropping all old patterns before applying new ones.
Sun, 13 Oct 2019 02:11:33 +0200 eol: cache needs update, also if it has same timestamp as the source
Mads Kiilerich <mads@kiilerich.com> [Sun, 13 Oct 2019 02:11:33 +0200] rev 43204
eol: cache needs update, also if it has same timestamp as the source Ignoring same timestamp could (in theory?) cause changes to not be detected. It might happen quite often that the cache is populated right after .hgeol has been updated and they thus have the same time stamp second. But we want correctness, and if it populates the cache so fast, then it can also not be a big problem to run it again next time when the timestamp has moved on.
Mon, 14 Oct 2019 01:33:18 +0200 eol: update isbinary filter to work without compat wrapper
Mads Kiilerich <mads@kiilerich.com> [Mon, 14 Oct 2019 01:33:18 +0200] rev 43203
eol: update isbinary filter to work without compat wrapper
Sun, 13 Oct 2019 02:05:19 +0200 localrepo: fix variable binding in handling of old filters
Mads Kiilerich <mads@kiilerich.com> [Sun, 13 Oct 2019 02:05:19 +0200] rev 43202
localrepo: fix variable binding in handling of old filters The lambda was referencing oldfn in outer scope without binding the current value. If oldfn function were reassigned before use, wrong filters could be used. Fixed by having oldfn as named parameter default value of the lambda.
Sun, 13 Oct 2019 14:40:00 +0200 localrepo: debug log of filter name when filtering through a function
Mads Kiilerich <mads@kiilerich.com> [Sun, 13 Oct 2019 14:40:00 +0200] rev 43201
localrepo: debug log of filter name when filtering through a function
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -24 +24 +50 +100 +300 +1000 +3000 tip