In D3976#64274, @yuja wrote:

Queued with minor cleanup, thanks.

As a follow up, can you fix hg grep --all-files -rREVS FILE to scan
unchanged revisions?

@yuja Cool, sending the option C now, will try out option D and send a patch if something comes up.

I also expect hg grep --all-files -r0+1 foo will show matches from both rev 0 and 1.

Suppose there are ten hits in 0 and the same 10 hits in 1, do you mean we print out all the 20 results, What purpose that would serve?

Keeping all ctx objects might use too much memory.

True I will change it to files[f] = True

I don't think we should omit files that were seen in earlier revisions

If I don't skip that would mean the same file in the same state being searched across all the revisions, and getting repetitive and redundant hits.

@yuja can you review this one

I created a new revision instead of updating the D3976, ignore this one.

So what's the next step should be ?

So what is the way around this, does this mean grep can't be changed at all
?
Also can't we update hglib to work accordingly.

Yeah

I am sorry I accidentally pushed here :/

I need some help with the tests failing here.

@yuja Sorry I didn't run the tests after this edit .

I am updating the tests

@martinvonz, thanks for the reviews, but @yuja has asked me to break this patch into three patches. So I guess this is not going to be merged anyway.

@yuja I am adding an --unmodified flag to change to change the mode to grep on the unmodified files as well.
What I am trying to do is ::

def fns_generator():
    if --unmodified:
        for f in ctx:
            for f in ctx:
                if match(f):
                    yield f
    else :
        for f in ctx.files():
            for f in ctx:
                if match(f):
                    yield f

Hey @yuja
Can you explain why you did this ?

Perhaps, we'll have to catch WdirUnsupported error to fall back to the filectx API.

@yuja
So I was working on it, but the way I tried to correct "wdir()" is by handling it as a special case, so introducing an "if" block again similar to this.
But you were asking to eliminate the if/else block altogether, I wonder if there is way ?

@yuja

fix grep -r 'wdir()'

@yuja Yeah, doing it right away, my bad. I should have based it on some revision which is already in the stable.

Since it required some explanation I have written a post on it.
http://sangeetmishra.me/2018/03/26/demonstrating-the-problem-with-forward-ordered-grep-all-in-mercurial.html

@yuja Can you please clarify this a bit more?

@pulkit It is not failing as of now. It's failing on the changes proposed by @durin42, which he assumed wont fail, but that's not the case!

Since the current code just overwrites message each time with the newer. What can be done to avoid losing the earlier message values?

@durin42 Should I make any changes?

@durin42 Here is the output! https://bpaste.net/show/7ccf4a9fea50

@pulkit Yeah, this rather a not so elegant hack. How can it be parsed in hg commit?
As the first message passed is overwritten by the second one at this step only. :/

@durin42 Even I thought of this construct before as it appears more elegant. But it is failing some tests!
Specifically, the error messages are changed in this one.

@jeffpc That means two new lines. Shall I edit this patch to effect that?