view tests/test-mq-qnew @ 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.
author FUJIWARA Katsunori <foozy@lares.dti.ne.jp>
date Tue, 19 May 2009 16:49:54 +0900
parents bd6deb7525f4
children f16ec85f125c
line wrap: on
line source

#!/bin/sh

echo "[extensions]" >> $HGRCPATH
echo "mq=" >> $HGRCPATH

hg init mq
cd mq

echo a > a
hg ci -Ama

echo '% qnew should refuse bad patch names'
hg qnew series
hg qnew status
hg qnew guards
hg qnew .hgignore

hg qinit -c

echo '% qnew with uncommitted changes'
echo a > somefile
hg add somefile
hg qnew uncommitted.patch
hg st
hg qseries
hg revert --no-backup somefile
rm somefile

echo '% qnew implies add'
hg qnew test.patch
hg -R .hg/patches st

echo '% qnew missing'
hg qnew missing.patch missing

echo '% qnew -m'
hg qnew -m 'foo bar' mtest.patch
cat .hg/patches/mtest.patch

echo '% qnew twice'
hg qnew first.patch
hg qnew first.patch

touch ../first.patch
hg qimport ../first.patch

echo '% qnew -f from a subdirectory'
hg qpop -a
mkdir d
cd d
echo b > b
hg ci -Am t
echo b >> b
hg st
hg qnew -g -f p
cat ../.hg/patches/p