Fri, 11 Dec 2020 15:25:11 +0100 debugdiscovery: fix swapped heads and roots
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 11 Dec 2020 15:25:11 +0100] rev 46111
debugdiscovery: fix swapped heads and roots Patch provided without comment… Differential Revision: https://phab.mercurial-scm.org/D9566
Fri, 11 Dec 2020 12:51:09 +0100 debugdiscovery: display the number of roundtrip used
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 11 Dec 2020 12:51:09 +0100] rev 46110
debugdiscovery: display the number of roundtrip used This is a good metric of the complexity of a discovery process. Differential Revision: https://phab.mercurial-scm.org/D9565
Fri, 11 Dec 2020 13:39:56 -0800 copies: make calculating lazy for dir move detection's "addedfiles"
Kyle Lippincott <spectral@google.com> [Fri, 11 Dec 2020 13:39:56 -0800] rev 46109
copies: make calculating lazy for dir move detection's "addedfiles" The information calculated here was only needed if (a) --debug was specified, or (b) a directory move was plausibly detected. With tree manifests (especially in my pathological repo and with our custom setup), pre-calculating the `u1` and `u2` can be quite slow, and it's not even necessary in many cases. Let's delay calculating it until we know it's actually necessary. This should have no observable differences in output. ### Performance I ran a rebase command in my pathological repo, rebasing two nodes across several public phase commits, but where no directory copies exist in any of the paths I'm tracking. #### Before ``` Time (mean ± σ): 3.711 s ± 0.061 s [User: 0.3 ms, System: 1.5 ms] Range (min … max): 3.640 s … 3.827 s 10 runs ``` #### After ``` Time (mean ± σ): 868.3 ms ± 10.1 ms [User: 0.5 ms, System: 1.2 ms] Range (min … max): 856.6 ms … 883.6 ms 10 runs ``` Differential Revision: https://phab.mercurial-scm.org/D9567
Tue, 08 Dec 2020 16:45:13 -0800 mergetools: add new conflict marker format with diffs in
Martin von Zweigbergk <martinvonz@google.com> [Tue, 08 Dec 2020 16:45:13 -0800] rev 46108
mergetools: add new conflict marker format with diffs in I use 3-way conflict markers. Often when I resolve them, I manually compare one the base with one side and apply the differences to the other side. That can be hard when the conflict marker is large. This patch introduces a new type of conflict marker, which I'm hoping will make it easier to resolve conflicts. The new format uses `<<<<<<<` and `>>>>>>>` to open and close the markers, just like our existing 2-way and 3-way conflict markers. Instead of having 2 or 3 snapshots (left+right or left+base+right), it has a sequence of diffs. A diff looks like this: ``` ------- base +++++++ left a -b +c d ``` A diff that adds one side ("diff from nothing") has a `=======` header instead and does not have have `+` prefixed on its lines. A regular 3-way merge can be viewed as adding one side plus a diff between the base and the other side. It thus has two ways of being represented, depending on which side is being diffed: ``` <<<<<<< ======= left contents on left ------- base +++++++ right contents on -left +right >>>>>>> ``` or ``` <<<<<<< ------- base +++++++ left contents on -right +left ======= right contents on right >>>>>>> ``` I've made it so the new merge tool tries to pick a version that has the most common lines (no difference in the example above). I've called the new tool "mergediff" to stick to the convention of starting with "merge" if the tool tries a regular 3-way merge. The idea came from my pet VCS (placeholder name `jj`), which has support for octopus merges and other ways of ending up with merges of more than 3 versions. I wanted to be able to represent such conflicts in the working copy and therefore thought of this format (although I have not yet implemented it in my VCS). I then attended a meeting with Larry McVoy, who said BitKeeper has an option (`bk smerge -g`) for showing a similar format, which reminded me to actually attempt this in Mercurial. Differential Revision: https://phab.mercurial-scm.org/D9551
Thu, 10 Dec 2020 14:39:22 -0800 diff: deprecate -r option
Martin von Zweigbergk <martinvonz@google.com> [Thu, 10 Dec 2020 14:39:22 -0800] rev 46107
diff: deprecate -r option The new `--from`/`--to` options should be enough to support all the uses cases and are easier to understand, so there is no reason that I'm aware of to use `-r` anymore. Differential Revision: https://phab.mercurial-scm.org/D9564
Thu, 10 Dec 2020 12:06:55 -0800 diff: update synopsis to use --from/--to instead of -r
Martin von Zweigbergk <martinvonz@google.com> [Thu, 10 Dec 2020 12:06:55 -0800] rev 46106
diff: update synopsis to use --from/--to instead of -r Differential Revision: https://phab.mercurial-scm.org/D9563
Thu, 10 Dec 2020 12:00:45 -0800 diff: describe behavior by using --from/--to instead of varying revision count
Martin von Zweigbergk <martinvonz@google.com> [Thu, 10 Dec 2020 12:00:45 -0800] rev 46105
diff: describe behavior by using --from/--to instead of varying revision count I very recently updated the documentation to prefer `--from`/`--to` over `-r`, but I missed the plain-text description of how the command behaves when given different numbers of revisions (I guess I just scanned the text for "-r"). This patch fixes that. Differential Revision: https://phab.mercurial-scm.org/D9562
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -7 +7 +10 +30 +100 +300 +1000 +3000 tip