quark added a comment.
In https://phab.mercurial-scm.org/D451#7698, @yuja wrote: > The point is these implementations would become invalid if `subset` were > optimized to "any" order. That's breaking change, but which is likely to be > not covered by tests. How about making `registrar.revsetpredicate` be conservative? If it sees any predicate registered with the old API, Disable `anyorder` optimization and change it to `followorder` in runtime? > As I said, most revset predicates have no explicit order. I introduced the > order flag in order to work around a few exceptions, which are `x:y`, > `x + y`, `sort()` and `reverse()`, IIRC. A strong "define" is exceptional. I feel it inconsistent if `x:y` has a strong order but `x::y` does not have. > So, is it really make sense to revamp the revset ordering rules? I don't > think so. I generally like this series, but -1 for bringing "any" order > everywhere. Maybe more conservative? Disable "anyorder" optimization unless: 1. A config flag was set 2. There is no user of 3-tuple registrar predicate I really like optimizations. REPOSITORY rHG Mercurial REVISION DETAIL https://phab.mercurial-scm.org/D451 To: quark, #hg-reviewers Cc: martinvonz, yuja, mercurial-devel _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
