Fri, 26 Apr 2024 19:10:35 +0100 dirstate: remove the python-side whitelist of allowed matchers
Arseniy Alekseyev <aalekseyev@janestreet.com> [Fri, 26 Apr 2024 19:10:35 +0100] rev 51626
dirstate: remove the python-side whitelist of allowed matchers This whitelist is too permissive because it allows matchers that contain disallowed ones deep inside, for example through `intersectionmatcher`. It is also too restrictive because it doesn't pass through some of the matchers we support, such as `patternmatcher`. It's also unnecessary because unsupported matchers raise `FallbackError` and we fall back anyway. Making this change makes more of the tests use rust code path, and therefore subtly change behavior. For example, rust status in largefiles repos seems to have strange behavior.
Fri, 26 Apr 2024 18:53:02 +0100 match: make `was_tampered_with` work recursively
Arseniy Alekseyev <aalekseyev@janestreet.com> [Fri, 26 Apr 2024 18:53:02 +0100] rev 51625
match: make `was_tampered_with` work recursively This is useful if we are to use it outside of Rust, when deciding whether or not to do some fast-path operation with a given matcher.
Fri, 26 Apr 2024 19:43:42 +0100 largefiles: mark more matchers as having been tampered with
Arseniy Alekseyev <aalekseyev@janestreet.com> [Fri, 26 Apr 2024 19:43:42 +0100] rev 51624
largefiles: mark more matchers as having been tampered with These happened to slip through the cracks earlier because they weren't caught by tests. Now that we're enabling rust fast path more widely these start breaking.
Mon, 06 May 2024 18:50:21 +0200 branching: merge stable into default
Raphaël Gomès <rgomes@octobus.net> [Mon, 06 May 2024 18:50:21 +0200] rev 51623
branching: merge stable into default
Mon, 06 May 2024 18:48:37 +0200 Added signature for changeset 028dc3f92dbd stable
Raphaël Gomès <rgomes@octobus.net> [Mon, 06 May 2024 18:48:37 +0200] rev 51622
Added signature for changeset 028dc3f92dbd
Mon, 06 May 2024 18:48:34 +0200 Added tag 6.7.3 for changeset 028dc3f92dbd stable
Raphaël Gomès <rgomes@octobus.net> [Mon, 06 May 2024 18:48:34 +0200] rev 51621
Added tag 6.7.3 for changeset 028dc3f92dbd
Mon, 06 May 2024 17:51:21 +0200 relnotes: add 6.7.3 stable 6.7.3
Raphaël Gomès <rgomes@octobus.net> [Mon, 06 May 2024 17:51:21 +0200] rev 51620
relnotes: add 6.7.3
Mon, 22 Apr 2024 19:47:08 +0200 rust: blanket implementation of Graph for Graph references stable
Georges Racinet <georges.racinet@octobus.net> [Mon, 22 Apr 2024 19:47:08 +0200] rev 51619
rust: blanket implementation of Graph for Graph references The need comes from the fact that `AncestorsIterator` and many Graph-related algorithms take ownership of the `Graph` they work with. This, in turn is due to them needing to accept the `Index` instances that are provided by the Python layers (that neither rhg nor `RHGitaly` use, of course): the fact that nowadays the Python layer holds an object that is itself implemented in Rust does not change the core problem that they cannot be tracked by the borrow checker. Even though it looks like cloning `Changelog` would be cheap, it seems hard to guarantee that on the long run. The object is already too rich for us to be comfortable with it, when using references is the most natural and guaranteed way of proceeding. The added test seems a bit superfleous, but it will act as a reminder that this feature is really useful until something in the Mercurial code base actually uses it.
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -8 +8 +10 +30 +100 +300 tip