log: rewrite default template to use labels (issue2866) This is a complete rewrite of the default template to use labels. This seems ultimately useless to me in most cases. The biggest benefit of this patch to me seems to be a fairly complicated example of the templating engine. It was a lot of hard work to figure out the precise acceptable syntax, since it's almost undocumented. Hat tip to Steve Losh's smartlog template, which helped me figure out a lot of the syntax. Hopefully later I can use the present default log template as an example for documenting the templating engine. A test is attached. My goal was to match the --color=debug output, which may differ slightly in newlines from the actual ANSI escape codes output. I consider this an acceptable invisible deviation. There seems to be a considerable slowdown with this rewrite. Before: $ time hg log -T default -r .~100::. > /dev/null real 0m0.882s user 0m0.812s sys 0m0.064s $ time hg log -T default -r .~100::. > /dev/null real 0m0.872s user 0m0.796s sys 0m0.068s $ time hg log -T default -r .~100::. > /dev/null real 0m0.917s user 0m0.836s sys 0m0.076s After: $ time hg log -T default -r .~100::. > /dev/null real 0m1.480s user 0m1.392s sys 0m0.072s $ time hg log -T default -r .~100::. > /dev/null real 0m1.500s user 0m1.400s sys 0m0.088s $ time hg log -T default -r .~100::. > /dev/null real 0m1.462s user 0m1.364s sys 0m0.092s Following the maxim, "make it work, profile, make it faster, in that order", I deem this slowdown acceptable for now. I suspect but have not confirmed that a big slowdown comes from calling keywords twice in the file templates, once to test the existence of output and again to actually list the output. If so, a simple speedup might be to improve the templating engine to cache keywords when called more than once on the same revision. TODO: I found a bug while working on this. The following stack traces: hg log -r . -T '{ifcontains(phase, "secret public", "lol", "omg")}\n'

log: do not hide the public phase in debug mode (BC) When 51fc43253a52 introduced phases to the `hg log --debug` output, it also disabled outputting public phase. At the same time, it always shows phases in the default template, `hg log --debug -T default`. Those two should produce the same output, but they don't. I think it makes a lot more sense to always show all phases. There's already loss of backwards compatibility in this case when using a newer hg on an old hg repo, since draft commits will show up in the output of `hg log --debug`. Finally, I just don't think that any sort of information should be hidden with --debug. This flag should be about showing as much information as possible.

templater: set the correct phase for parents Akin to f6371cc62d2a which did this for `hg log`, the following sets the correct phase for the {phase} keyword when the context is a parent of the current cset. This allows templates such as the following to be defined, parent = '{label("log.parent changeset.{phase}", "parent: {rev}:{node|formatnode}")}\n' which when called on a parent (e.g. with the `parents` template keyword), will produce the correct phase.

color: omit debug label output on empty strings This is most noticeable when using custom templates. Before this patch, a template like {label("foo.bar", baz)} would emit [foo.bar|] whenever baz was empty. This cset simply omits all output when baz is empty.

tests: make hghave list features alphabetically

revset: remove the now unused _descgeneratorset class

revset: use _generatorset in _revancestors The _descgeneratorset class is going away.

revset: remove now unused class _ascgeneratorset

revset: use _generatorset directly in _revdescendant _ascgeneratorset is going away.

generatorset: move membership testing on ordered gen to the main class We are phasing out the ordered version of the class to simplify the code.

generatorset: make use of the new mechanism in the subclass Until we remove them, we use the new parameter of _generatorset to make sure the code is run.

generatorset: make it possible to use gen as fastasc or fastdesc We gain a parameter to inform that the generator is ascending or descending. If the generator is ordered, it is also used for the `fastasc` or `fastdesc` version. The _ascgeneratorset and _descgeneratorset class will be removed soon.

baseset: rely on the abstractsmartset implementation for filter

_orderedsetmixin: drop this now unused class All my friends are dead.

spanset: drop _orderedsetmixin inheritance The min/max method are as well provided by abstractsmartset.

orderedlazyset: drop this now unused class All my friends are dead.

_descendant: use filteredset instead of orderedlazyset The orderedlazyset class is going away. Filteredset gives the same service.

addset: use the base implementation for ascending and descending

addset: use base implementation for __filter__

addset: use base implementation for __add__

addset: use base implementation for __sub__

addset: use base implementation for __and__

addset: promote to real smartset Better revset performance are also achieved with less overlay. There is no good reason for addset to not be a smartset. We can replace the `_orderedsetmixin` inheritance since `abstractsmartset` has efficient min and max too.

addset: add a __nonzero__ method This is required to be a full smartset (not sure what was happening before that...)

addset: offer a fastasc and fastdesc methods If the underlying object offers fast iterators, we use them to provide fast iterators too.

addset: split simple and ordered iteration We have two goals here. First, we would like to restore the former iteration order we had in 2.9. Second, we want this logic to be reusable for `fastasc` and `fastdesc` methods.

generatorset: promote to smartset This is not going to be efficient but we need all basic set classes to be smartsets for the other classes to work.

generatorset: implement __nonzero__ This is necessary to become a real smartset.

spanset: use base implementation for __add__

spanset: use base implementation for __sub__

spanset: use base implementation for __and__

spanset: use base implementation for filter

filteredset: use base implementation for filter

filteredset: use base implementation for __add__

filteredset: use base implementation for __sub__

filteredset: use base implementation for __and__

abstractsmartset: add default implementation for __sub__

abstractsmartset: add default implementation for __add__

abstractsmartset: add default implementation for __and__

abstractsmartset: add default implementation for filter

lazyset: rename the class to filteredset All smartsets try to be lazy. The purpose of this class is to apply a filter on another set. So we rename the class (and all its occurences) to `filteredset`.

lazyset: add order awareness to the class Just a bit of extra code makes the lazyset aware of order. This renders orderedlazyset useless. At some point, the `subset` will become responsible for this ordering logic. But we are not there yet because the various objects used as subsets are not good enough.

lazyset: remove min/max This is now handled by abstractsmartset.

baseset: remove min/max methods This is now handled by the base class.

abstractsmartset: add a default implementation for min and max This default implementation takes advantage of the fast iterator if available.

lazyset: drop now useless ascending/descending definition

lazyset: inherit the fastasc and fastdesc method from subset When the filtered subset has such methods, we can use them. It is implemented as properties to be able to quickly return None if no corresponding fastasc exists on the subset.

lazyset: split the iteration logic from the condition filtering logic So that the filter can be reused by `fastasc` or `fastdesc`.