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

     1

== New Features ==

     2

     3

 * There is a new config section for templates used by hg commands. It

     4

   is called `[command-templates]`. Some existing config options have

     5

   been deprecated in favor of config options in the new

     6

   section. These are: `ui.logtemplate` to `command-templates.log`,

     7

   `ui.graphnodetemplate` to `command-templates.graphnode`,

     8

   `ui.mergemarkertemplate` to `command-templates.mergemarker`,

     9

   `ui.pre-merge-tool-output-template` to

    10

   `command-templates.pre-merge-tool-output`.

    11

    12

 * There is a new set of config options for the template used for the

    13

   one-line commit summary displayed by various commands, such as `hg

    14

   rebase`. The main one is `command-templates.oneline-summary`. That

    15

   can be overridden per command with

    16

   `command-templates.oneline-summary.<command>`, where `<command>`

    17

   can be e.g. `rebase`. As part of this effort, the default format

    18

   from `hg rebase` was reorganized a bit.

    19

    20

 * `hg strip`, from the strip extension, is now a core command, `hg

    21

   debugstrip`. The extension remains for compatibility.

    22

    23

 * `hg diff` now supports `--from <rev>` and `--to <rev>` arguments as

    24

   clearer alternatives to `-r <revs>`. `-r <revs>` has been

    25

   deprecated.

    26

    27

 * The memory footprint per changeset during pull/unbundle

    28

   operations has been further reduced.

    29

    30

 * There is a new internal merge tool called `internal:mergediff` (can

    31

   be set as the value for the `merge` config in the `[ui]`

    32

   section). It resolves merges the same was as `internal:merge` and

    33

   `internal:merge3`, but it shows conflicts differently. Instead of

    34

   showing 2 or 3 snapshots of the conflicting pieces of code, it

    35

   shows one snapshot and a diff. This may be useful when at least one

    36

   side of the conflict is similar to the base.

    37

    38

== New Experimental Features ==

    39

    40

* `experimental.single-head-per-branch:public-changes-only` can be used

    41

  restrict the single head check to public revision. This is useful for

    42

  overlay repository that have both a publishing and non-publishing view

    43

  of the same storage.

    44

    45

    46

== Bug Fixes ==

    47

    48

    49

    50

== Backwards Compatibility Changes ==

    51

    52

    53

    54

== Internal API Changes ==

    55

    56