rebase: use matcher to optimize manifestmerge The old merge code would call manifestmerge and calculate the complete diff between the source to the destination. In many cases, like rebase, the vast majority of differences between the source and destination are irrelevant because they are differences between the destination and the common ancestor only, and therefore don't affect the merge. Since most actions are 'keep', all the effort to compute them is wasted. Instead, let's compute the difference between the source and the common ancestor and only perform the diff of those files against the merge destination. When using treemanifest, this lets us avoid loading almost the entire tree when rebasing from a very old ancestor. This speeds up rebase of an old stack of 27 commits by 20x. In mozilla-central, without treemanifest, when rebasing a commit from default~100000 to default, this speeds up the manifestmerge step from 2.6s to 1.2s. However, the additional diff adds an overhead to all manifestmerge calls, especially for flat manifests. When rebasing a commit from default~1 to default it appears to add 100ms in mozilla-central. While we could put this optimization behind a flag, I think the fact that it makes merge O(number of changes being applied) instead of O(number of changes between X and Y) justifies it.

     1

Our full contribution guidelines are in our wiki, please see:

     2

     3

https://www.mercurial-scm.org/wiki/ContributingChanges

     4

     5

If you just want a checklist to follow, you can go straight to

     6

     7

https://www.mercurial-scm.org/wiki/ContributingChanges#Submission_checklist

     8

     9

If you can't run the entire testsuite for some reason (it can be

    10

difficult on Windows), please at least run `contrib/check-code.py` on

    11

any files you've modified and run `python contrib/check-commit` on any

    12

commits you've made (for example, `python contrib/check-commit

    13

273ce12ad8f1` will report some style violations on a very old commit).