view tests/test-rename-after-merge @ 8849:80cc4b1a62d0

compare grep result between target and its parent

I found that typical case is that grep target is added at (*) revision
in the tree shown below.

     +--- 1(*) --- 3
     0
     +--- 2 ------ 4

Now, I expect 'hg grep --all' to show only rev:1 which is first
appearance of target line.

But 'hg grep --all' will tell:

  target line dis-appeared at 3 => 4
  target line     appeared at 2 => 3
  target line dis-appeared at 1 => 2
  target line     appeared at 0 => 1

because current 'hg grep' implementation compares not between target
revision and its parent, but between neighbor revisions in walkthrough
order.

I checked performance of this patch by "hg grep --follow --all
walkchangerevs" on whole Mercurial repo, and patched version could
complete as fast as un-patched one.

#!/bin/sh

# Test issue 746: renaming files brought by the
# second parent of a merge was broken.

echo % create source repository
hg init t
cd t
echo a > a
hg ci -Am a
cd ..

echo % fork source repository
hg clone t t2
cd t2
echo b > b
hg ci -Am b

echo % update source repository
cd ../t
echo a >> a
hg ci -m a2

echo % merge repositories
hg pull ../t2
hg merge
hg st

echo % rename b as c
hg mv b c
hg st
echo % rename back c as b
hg mv c b
hg st
cd ..

# Test issue 1476: renaming a first parent file into
# another first parent file while none of them belong to
# the second parent was broken
echo % test issue 1476
hg init repo1476
cd repo1476
echo a > a
hg ci -Am adda
echo b1 > b1
echo b2 > b2
hg ci -Am changea
hg up -C 0
echo c1 > c1
echo c2 > c2
hg ci -Am addcandd
echo % merge heads
hg merge
hg mv -Af c1 c2
echo % commit issue 1476
hg ci -m merge
hg log -r tip -C -v | grep copies
hg rollback
hg up -C .
echo % merge heads again
hg merge
hg mv -Af b1 b2
echo % commit issue 1476 with a rename on the other side
hg ci -m merge
hg log -r tip -C -v | grep copies