Summary: Also change the internal API so it no longer accepts the "heads" argument.
Reviewed By: ryanmce
Differential Revision: D6745865
fbshipit-source-id: 368742be49b192f7630421003552d0a10eb0b76d
`hg show` makes heavy use of shortest() to limit the length of the node
hash.
For the "stack" and "work" views, you are often looking at multiple
lines of similar output for "lines" of work. It is visually appeasing
for things to vertically align. A naive use of {shortest(node, N)}
could result in variable length nodes and for the first character of
the description to vary by a column or two.
We implement a function to determine the longest shortest prefix for
a set of revisions. The new function is used to determine the printed
node length for all `hg show` views.
.. feature::
show: use consistent node length in views
Our previous shortest node length of 5 was arbitrarily chosen.
shortest() already does the work of ensuring that a partial node
isn't ambiguous with an integer revision, which is our primary risk
of a collision for very short nodes. It should be safe to go with the
shortest node possible.
Existing code is also optimized to handle nodes as short as 4.
So, we decrease the minimum hash length from 5 to 4.
We also add a test demonstrating that prefix collisions increase the
node length.
.. feature::
show: decrease minimum displayed hash length from 5 to 4
Differential Revision: https://phab.mercurial-scm.org/D558
This commit addresses a number of deficiencies in `hg show work`'s
output:
* Failure to render tags (it just wasn't implemented)
* Failure to render names associated with non-built-in namespaces
(e.g. remotenames)
* Color names were hardcoded instead of coming from the canonical
source in the namespace
This change has the intended effect of rendering tags and extra
namespaces. It solves an immediate need at Mozilla of having
names from a custom namespace printed, which is blocking us from
switching from a custom `hg wip` revset/template combo to `hg show
work`.
Note that the order of branches and bookmarks changes. This is
because bookmarks are registered before branches in namespaces.py.
We may want to register them last, after tags and branches. Or we
may want to added a weighted field to the namespace to control
display order. Something to think about.
I'm not a big fan of the complexity in the templating layer. There
is a lot of code to basically filter out the special case of
branch=='default' and tag=='tip'. Ideally, we would iterate over
a data structure that had irrelevant/unwanted names pre-filtered.
However, I wasn't sure how to best implement this. We probably
want {namespaces} to emit everything (its current behavior). I
was toying with the following:
* {namespacesnondefaults} variation that filtered values
* A filter function that operated on {namespaces} (I wasn't sure
how to implement this since the filtering layer would see a
"hybrid" instance as opposed to something that was definitely
an iterable of namespaces.)
* A namespaces(...) function where you could specify which values
to return. I like this the most. But it really wants named
arguments to control filtering and we only support named arguments
on revsets, not templates.
I figure perfect is the enemy of good and we can refine templating
support for namespaces in the future. At least now we have a
concrete example of a use case.
Durham and I both like this better than "underway." We can add aliases
and bikeshed on the name during the 4.3 cycle, as this whole extension is
highly experimental.
