commitextras: mark the extension as ADVANCED

run-tests: check if stream is a tty before using color Previous implementation (e80041832eec) checked only if sys.stderr was a tty which was less general. Also makes sure that colors is never used if pygments is not available, irrespective of --color flag value.

tests: rewrite test-rebase-detach.t using drawdag This makes it much clearer because each test case can have exactly the graph it wants (no extra cruft just because other tests want it). Differential Revision: https://phab.mercurial-scm.org/D94

tests: simplify config in test-rebase-detach.t Differential Revision: https://phab.mercurial-scm.org/D93

drawdag: include files from both parents in merge commits Consider a graph like this: D |\ B C |/ A drawdag will add a file called A in commit A, file B in B, file C in C. That's fine and expected. In merge commits like D, I would expect the files and their contents to be taken from the parent commits, so commit D in this example would have files A, B, and C. However, drawdag will instead add the file D compared to the first parent. Depending on whether B or C got a smaller nodeid, the contents of D would be {A, B, D} or {A, C, D}. This patch changes it to to be {A, B, C}. Differential Revision: https://phab.mercurial-scm.org/D92

gitweb: preserve whitespace in description Without this, multiple spaces or tabs in the commit message aren't preserved and things like tables don't align properly. As part of adding the CSS rule, we had to cuddle the content with the <div> to not introduce leading and trailing whitespace. The "addbreaks" filter was also removed because it would insert an additional newline, effectively double spacing content. Differential Revision: https://phab.mercurial-scm.org/D113

sparse: add a requirement when a repository uses sparse (BC) The presence of a sparse checkout can confuse legacy clients or clients without sparse enabled for reasons that should be obvious. This commit introduces a new repository requirement that tracks whether sparse is enabled. The requirement is added when a sparse config is activated and removed when the sparse config is reset. The localrepository constructor has been taught to not open repos with this requirement unless the sparse feature is enabled. It yields a more actionable error message than what you would get if the lockout were handled strictly at the requirements verification phase. Old clients that aren't sparse aware will see the generic "repository requires features unknown to this Mercurial" error, however. The new requirement has "exp" in its name to reflect the experimental nature of sparse. There's a chance that the eventual non-experimental feature won't change significantly and we could have squatted on the "sparse" requirement without ill effect. If that happens, we can teach new clients to still recognize the old name. But I suspect we'll sneak in some BC and we'll want a new requirement to convey new meaning. Differential Revision: https://phab.mercurial-scm.org/D110