copies: use intersectmatchers() in non-merge p1 optimization This enables the optimization introduced by d4247c306d82 for non-rebase cases. Before, the match couldn't be narrowed if it was e.g. alwaysmatcher. The logic is copied from bd56bea5ecf8.

run-tests: pre instantiate pygments objects Pre instantiate pygments objects to minimize overhead (cf. 20436925e080)

merge with stable

rebase: only change self.state when collapsing in _finishrebase When the code executes to _finishrebase, self.state should be populated with correct destinations and do not need to be written to a node. The code was introduced by 8dc45c9059, which seems to avoid setting state values to None but it didn't provide more details. Differential Revision: https://phab.mercurial-scm.org/D346

rebase: choose merge base without unwanted revisions Previously, when there are 2 merge base candidates, we choose p1 blindly, which may make the merge result to have "unwanted content". This patch makes rebase smarter - choose a merge base that does not have "unwanted revs" if possible. Since we don't really have a good solution when there are "unwanted revs", abort in that case. Differential Revision: https://phab.mercurial-scm.org/D340

templatekw: choose {latesttag} by len(changes), not date (issue5659) As Augie reported in the bug, the current heuristic of choosing the best tag of a merge commit by taking the one with newest tag (in terms of tagging date) currently fails in the Mercurial repo itself. Copying the example from Yuya: $ hg glog -T '{node|short} {latesttag}+{latesttagdistance}\n' \ -r '4.2.3: & (merge() + parents(merge()) + tag())' o 02a745c20121 4.2.3+5 |\ | o 86aca74a063b 4.2.3+4 | |\ | | o e6d8ee3c9ec3 4.3-rc+109 | | | | | ~ o | a3ce07e2dde5 4.3.1+2 : | o | 3fee7f7d2da0 4.3.1+0 |/ o 98e990bb7330 4.2.3+3 |\ | ~ o 506d7e48fbe6 4.2.3+2 : o 943c91326b23 4.2.3+0 | ~ It seems to me like the best choice is the tag with the smallest number of changes since it (across all paths, not the longest single path). So that's what this patch does, even though it's costly. Best-of-5 timings for Yuya's command above shows a slowdown from 1.293s to 1.610s. We can optimize it later. Differential Revision: https://phab.mercurial-scm.org/D447

tests: use graph log in {latesttag} tests The tests are much easier to read if one does not have to re-read the setup part all the time to understand the graph shape. Differential Revision: https://phab.mercurial-scm.org/D446

demandimport: disable if chg is being used In chg's case, making modules lazily loaded could actually slow down things since chg pre-imports them. Therefore disable demandimport if chg is being used. This is not done by setting `HGDEMANDIMPORT` chg client-side because that has side-effects on child processes (hooks, etc). Differential Revision: https://phab.mercurial-scm.org/D351

demandimport: move HGDEMANDIMPORT test to __init__.py The logic is now shared between demandimport{2,3}. Differential Revision: https://phab.mercurial-scm.org/D445

log: add a "graphwidth" template variable Wrapping text in templates for 'hg log --graph' can't be done very well, because the template doesn't know how wide the graph drawing is. The edge drawing function needs to know the number of lines in the template output, so we need to also determine how wide that drawing would be before we call the edgefn or evaluate the template. This patch makes edgefn compute the graph width and pass it into the template so that we can do something like this: COLUMNS=10 hg log --graph --template "{fill(desc, termwidth - graphwidth)}" @ a a a a | a a a a | a a a a o a a a |\ a a a | | a a a | | a a a Using extensions to do this would be relatively complicated due to a lack of hooks in this area of the code. In the future it may make sense to have a more generic "textwidth" that tells you how many columns you can expect to fill without causing the terminal to wrap your output. I'm not sure there are other situations to motivate this yet, or if it is entirely feasible. Differential Revision: https://phab.mercurial-scm.org/D360