exthelper: add some semi-useful trace logs It'd be nice to make the trace functions a little better-named in the output, but I'm not sure how much better we can do without overhead. This at least lets you see if a single reposetup function is eating all the time or if it's spread over all of them. I needed this because Google's uber-extension has a long load time and I wasn't sure where the problem was. Differential Revision: https://phab.mercurial-scm.org/D6381

help: add missing blank line, making "revlog-compression" show up Differential Revision: https://phab.mercurial-scm.org/D6386

tests: fix share test to actually share the repo "repo2" is clearly meant to be a share from "repo1" but without sharing bookmarks. However, `hg unshare` was called in the repo, so it had become completely unrelated and thus not testing what it was supposed to test. Differential Revision: https://phab.mercurial-scm.org/D6385

tests: separate out bookmarks tests from test-share.t Differential Revision: https://phab.mercurial-scm.org/D6384

bookmarks: use vfs.tryread() instead of reimplementing it Differential Revision: https://phab.mercurial-scm.org/D6383

bookmarks: use context manager when writing files Differential Revision: https://phab.mercurial-scm.org/D6382

bisect: do not crash with rewritten commits

log: add config for making `hg log -G` always topo-sorted I (and everyone else at Google) have an log alias that adds graph mode and templating. I have another one that builds on the first and also restricts the set of revisions to only show those I'm most likely to care about. This second alias also adds topological sorting. I still sometimes use the first one. When I do, it very often bothers me that it's not topologically sorted (branches are interleaved). This patch adds a config option for always using topological sorting with graph log. The revision set is sorted eagerly, which seems like a bad idea, but it doesn't seem to make a big difference in the hg repo (150ms). I initially tried to instead wrap the user's revset in sort(...,topo), but that seemed much harder. Differential Revision: https://phab.mercurial-scm.org/D6331

log: remove an unnecessary "and opts.get('rev')" condition As Yuya pointed out, the condition is unnecessary since revs.isdescending() would be true if --follow without --rev. Differential Revision: https://phab.mercurial-scm.org/D6372

graphmod: remove support for graph lines mixing parent/grandparent styles (BC) Currently, if the configuration for a graph edge draw style has multiple bytes (at least on python2), it is interpreted as "this is a request to draw the line partially in the style of the parent, partially in the style of the grandparent". This precludes the configuration handling unicode characters (which trigger the `len > 1` check, at least on python2), and I believe was part of the reason that beautifygraph was written the way it was. Talking with the person who implemented this, it appears to have been to achieve feature parity with the rendering of the smartlog extension. I suspect that this isn't actually used outside of that situation, so I think that we can remove it without much issue. This will make it so that multi-character edges are possible, and render any existing configuration that uses this feature with these multiple characters. This is *not* going to adjust the width of everything to make it line up correctly, please see the test that's being modified in this changeset for an example of how the previous configuration now renders. Note also that the previous configuration seems to have been broken, or at least it was behaving in a really non-obvious way - it was avoiding the grandparent character(s) when it should have been displaying them! This is why so many "!" characters changed to "3."; I don't know if this was intentional. Differential Revision: https://phab.mercurial-scm.org/D5112