ui: disable echo back of prompt input if ui is set to non-tty purposely

9ab18a912c44 is nice for test output, but it also affects command-server
channel.  Command-server client shouldn't receive echo-back message, which
makes it harder to parse the output.
revlog: mark nullhash as module-private

No other module should ever need this, so mark it with _ so nobody
tries to use it.
revlog: move references to revlog.hash to inside the revlog class

This will make it possible for subclasses to have different hashing
schemes when appropriate. I anticipate using this in manifests.

Note that there's still one client of mercurial.revlog.hash() outside
of revlog: mercurial.context.memctx uses it to construct the file
entries in an in-memory manifest. I don't think this will be a problem
in the immediate future, so I've left it as-is.
manifest: move manifest parsing to module-level

We'll need this in the sharded manifest hashing routine, and I need to
tweak it anyway, so make it module-level now.
manifest: simplify manifest.add() by making args required

I verified that changed was never false (it was always a 2-tuple) by
adding

@@ -220,6 +225,8 @@ class manifest(revlog.revlog):

     def add(self, map, transaction, link, p1=None, p2=None,
             changed=None):
+        if not changed:
+            assert False, 'changed was %r' % changed
         # if we're using the cache, make sure it is valid and
         # parented by the same node we're diffing against
         if not (changed and p1 and (p1 in self._mancache)):

and observing that the test suite still passed. Making all the
arguments required should help future readers understand what's going
on here.
manifest: rearrange add() method and add comments for clarity

Omit the check of bool(p1) since it's always true in practice: it will
either be nullid or some valid manifest sha, and we know nullid won't
ever be in the cache so we can simplify understanding of this code.
rebase: attempt to clarify --base
rebase: add help examples
addset: use the ascending argument in _iterordered

Fix a bug where fastasc and fastdesc were iterator in the same order as
self._ascending.

--HG--
extra : rebase_source : dd92c3fbce9c8c50ca6319eb03c8e6f0054e7291
addset: this is a smartset, update the docstring

The documentation was still stating that this class is a not a smartset. We drop
that part.

--HG--
extra : rebase_source : 3406c4437813936a6a40326de6f5ac39908c4597
addset: drop the leading underscore from the class name

This class is now a real smartset.

--HG--
extra : rebase_source : db18c7722463904d9ac77d29af1ae7108598a64f
generatorset: update the docstring now that it is a smartset

The documentation was still stating that this class was not a smartset. We drop
that part.

--HG--
extra : rebase_source : 1353e98e5804cc2d6a0ddc5cbb4761c6a8078eb2
generatorset: drop the leading underscore in the class name

This is a real smart set now.

--HG--
extra : rebase_source : bdfe01423b9096ddfa1f86ec606cadb7c0ce6ebc
generatorset: stop using a base as the _genlist

It does not add anything and makes it more complicated to have a simple baseset
implementation.

--HG--
extra : rebase_source : 46196a89537dd360cb8c3f57da8533ff22d9b827
generatorset: move iteration code into _iterator

_iterator handles the generator iteration. The `__iter__` method will need
changes to handle ordering-related information.

--HG--
extra : rebase_source : 6194577268d6ebda3414dceb5850e11cb6eb6de8
generatorset: get list-based fast iterations after the generator is consumed

When all revisions are known, we shortcut most of the class logic to use list
iteration instead. The cost of the sort is expected to be non-significant. The
list creation and sorting could be done lazily in the future. We have to copy
the list to not break existing iterator created before we finished consuming the
generator.

--HG--
extra : rebase_source : 202c01b8861780d436eb1db65228c21e76122465
addset: drop caching through generatorset

The utility of this cache is debatable (no visible benchmark impact) and using
generatorset for such purpose makes the code complicated.

We drop it for now. Someone can reintroduce a smart version of it in the future
if it is detected to be relevant.

--HG--
extra : rebase_source : 8cabb311fd603322d00333cc811388cba0961747
generatorset: explicitly track iteration order

The expected iteration order may be different than the fast iteration order (eg:
ancestors(42) is expected to be iterated upward but is fast/lazy to compute
downward.

So we explicitly track the iteration order and enforce it if the manual
iteration is requested.

Default expected iteration order of a generator set is ascending because I'm
not aware of any descending revset that need a generatorset. The first to find
such descending revset will have the pleasure to make this configurable.

--HG--
extra : rebase_source : 595144ea56de6147517252466e8b34fbe053c1c7
generatorset: implement isascending and isdescending

--HG--
extra : rebase_source : a08d73245e677586c8c71a5812a682ef1a879525
baseset: use default value instead of [] when possible

For pure cleanup purposes, we replace all the occurences of `baseset([])` with
`baseset()`.

--HG--
extra : rebase_source : 6487e157d7c41509c2c73e604e7a83d7eacae5c0