view tests/test-mq-missingfiles.out @ 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 a96b049075a8
children 561ff8d9e4f0
line wrap: on
line source

adding b
patch queue now empty
% push patch with missing target
applying changeb
unable to find 'b' for patching
2 out of 2 hunks FAILED -- saving rejects to file b.rej
patch failed, unable to continue (try -v)
patch failed, rejects left in working dir
errors during apply, please fix and refresh changeb
% display added files
a
c
% display rejections
--- b
+++ b
@@ -1,3 +1,5 @@
+b
+b
 a
 a
 a
@@ -8,3 +10,5 @@
 a
 a
 a
+c
+c
adding b
patch queue now empty
% push git patch with missing target
applying changeb
unable to find 'b' for patching
1 out of 1 hunks FAILED -- saving rejects to file b.rej
patch failed, unable to continue (try -v)
b: No such file or directory
patch failed, rejects left in working dir
errors during apply, please fix and refresh changeb
? b.rej
% display added files
a
c
% display rejections
--- b
+++ b
GIT binary patch
literal 2
Jc${No0000400IC2

% test push creating directory during git copy or rename
adding a
patch queue now empty
applying patch
now at: patch