[PATCH 1 of 5 V2] revsets: record sort order keys

Yuya Nishihara yuya at tcha.org
Mon May 30 08:56:53 EDT 2016


On Sun, 29 May 2016 09:57:34 -0700, Martijn Pieters wrote:
> On 26 May 2016 at 06:00, Yuya Nishihara <yuya at tcha.org> wrote:
> > This patch seems to try hard to preserve raw sort key strings, but they
> > aren't exactly the same as what sort() would do. That made me feel keeping
> > raw sort keys wouldn't be nice.
> 
> They produce sorted output that still honours the (informative) sort
> key. I could add a clarification to the docstring here that
> `reversed(sort(set, keys))` produces slightly different output from
> `sort(set, reversedkeys)` where the input order is reversed for any
> entry where the sort keys are equal. If someone cares about the sort
> order beyond the sort keys they need to re-sort explicitly.

Perhaps nobody would care that. We only care 'rev', '-rev' and 'topo' right
now, and the first two are .isascending() and .isdescending(). We could
introduce a general .sortorder attribute at the cost of boring string
manipulation, but I don't see it would be useful. Plus, it doesn't always
agree with sort(). That's why I thought .istopo() would be simpler.

BTW, we'll have to normalize 'author' and 'user'.

> > Perhaps adding istopo() or something would be simpler.
> 
> You'd still have to track that across multiple predicates; I tried
> that as a first step but it wasn't any simpler really.

I meant set.istopo() in place of set.sortorder. I didn't mean
istopo(revset_expr), which would be doable but not simple because multiple
predicates may be reordered by their weights.


More information about the Mercurial-devel mailing list