Reverse the way backout is doing the merge Currently, backout is creating a backout revision as a child node of the backed out node and will leave you at this new head. This has several drawbacks: * this changes the current head * when there is a long history between the backed out node and the current head, this will generate a huge number of diffs that are scary at first sight, and not very natural to review before commit. The change consists to switch back to the original node as soon as the backout node (which becomes the new tip) has been created. Then the --merge option can just merge this new tip in the current node. * the current head/node is not changed from the user's point of view * even without using the --merge option, the backout revision is still easy to locate, as this is the tip * the merge is much more intuitive as diffs of the merge is right you are looking to backout

     1

#!/bin/sh

     2

     3

cat <<EOF > merge

     4

import sys, os

     5

print "merging for", os.path.basename(sys.argv[1])

     6

EOF

     7

HGMERGE="python ../merge"; export HGMERGE

     8

     9

mkdir A1

    10

cd A1

    11

hg init

    12

echo This is file foo1 > foo

    13

echo This is file bar1 > bar

    14

hg add foo bar

    15

hg commit -m "commit text" -d "1000000 0"

    16

    17

cd ..

    18

hg clone A1 B1

    19

    20

cd A1

    21

rm bar

    22

hg remove bar

    23

hg commit -m "commit test" -d "1000000 0"

    24

    25

cd ../B1

    26

echo This is file foo22 > foo

    27

hg commit -m "commit test" -d "1000000 0"

    28

    29

cd ..

    30

hg clone A1 A2

    31

hg clone B1 B2

    32

    33

cd A1

    34

hg pull ../B1

    35

hg merge

    36

hg commit -m "commit test" -d "1000000 0"

    37

echo bar should remain deleted.

    38

hg manifest --debug

    39

    40

cd ../B2

    41

hg pull ../A2

    42

hg merge

    43

hg commit -m "commit test" -d "1000000 0"

    44

echo bar should remain deleted.

    45

hg manifest --debug