- User Since
- Feb 8 2018, 2:14 AM (223 w, 3 d)
Jun 10 2019
The commit message has diff which confuses hg import. You need to indent those diffs.
Also, remove the pastebin links as they are not required since we have diffs.
Download this bundle : http://bit.ly/2DuJjsS
This link asks me to login. So definitely not a good link to put in commit message.
My understanding is that the 1st patch should be present in the mercurial installed in the system, which is what you said right? If that's correct, we can go ahead and have this whole as one patch as I don't think people usually do install system hg on patch to patch basis.
May 15 2019
May 10 2019
Oh, nice! I sometimes use run-tests.py -i and just accept an unreadable diff because I know that hg diff might make it easier to read. I had not understood why :)
Glad to know you will be helped :)
Feb 19 2019
Apologies, I didn't run the tests after the latest addition. 😔
Hey @durin42 , take a look at the changes when you get time.
Feb 13 2019
Feb 9 2019
Jan 10 2019
Jan 9 2019
@durin42 So the try/except will fall back to unified diff?
Is there a way we can enforce this on system's that don't have mercurial installed globally and not have to fall back on the earlier practice.
Jan 7 2019
Note: To see this in action, one needs to add the changes from this mdiff.py to the mdiff.py of their installed mercurial.
This is because unless you do that, you cannot import mdiff.new_patch as that function won't be there in your installed version, and hence it will keep falling back to the unified_diff.
Nov 3 2018
This passes the tests now. I had missed the subsequent code that was dependent on the earlier initialisation of self._testdir.
I passed the wrong revision number in the -r flag.
This was an error. Ignore, something went wrong.
Oct 31 2018
Aug 9 2018
Aug 8 2018
Aug 7 2018
Aug 5 2018
Aug 4 2018
@yuja Cool, sending the option C now, will try out option D and send a patch if something comes up.
Aug 3 2018
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.
Jul 30 2018
@yuja can you review this one
Jul 25 2018
I created a new revision instead of updating the D3976, ignore this one.
Jul 13 2018
So what's the next step should be ?
Jul 11 2018
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.
Jul 10 2018
Jul 9 2018
Jul 7 2018
Jul 5 2018
Jul 3 2018
Jul 2 2018
I am sorry I accidentally pushed here :/
Jun 28 2018
Jun 21 2018
I need some help with the tests failing here.
Jun 19 2018
Jun 17 2018
@yuja Sorry I didn't run the tests after this edit .
Jun 16 2018
Jun 15 2018
Jun 13 2018
I am updating the tests
Jun 12 2018
Jun 11 2018
@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
Jun 5 2018
Can you explain why you did this ?
Jun 2 2018
May 30 2018
May 26 2018
Perhaps, we'll have to catch WdirUnsupported error to fall back to the filectx API.
May 24 2018
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 ?
Apr 17 2018
fix grep -r 'wdir()'