GSoC Blog post #7

This week I worked on passing multiple revisions to the –allfiles flag.

The PR can be found at

It’s assumed that if you are passing multiple revisions to –allfiles,
you want hits from all of them. This was the behaviour that was chose after a discussion with Yuya.

The initial patch that I had sent had a different behaviour.

It made sure it just check the files only once by maintaining a dictionary called files. If there is a file that was used to be tracked by the repo but was subsequently deleted in a revision, and that revision falls between your specified range of revisions, you would get results from that file too.

This completes the overhaul of grep. There is one more thing that is left is :

hg grep --all-files -rREVS FILE to scan unchanged revisions?

Although this marks the end of the GSoC coding period, my association with Mercurial shall continue for the times to come.

GSoC Blog post #6

At the beginning of this week, my previous commit was revert and set to config = False, meaning that it is hidden behind that config option. That’s because it was a period of code freeze in mercurial as the next release is due in some days, so unless a feature is completely tested it can’t be released.

Link to the revision:

Next Yuya told me to work on passing multiple revisions with –all-files mode.

I have had some code developments related to it posted on BitBucket.

The work is currently in progress at

This patch needs to handle some edge cases which I am trying to figure out like making it compatible with –diff flag, also this needed to be backed up some testing, which I am writing as of now. This is the final leg of my proposal. Rest remaining is documentation and writing more steps.


GSOC Blog Post #5

This time I was working on changing the default of the grep command to a new behaviour.

With this patch grep searches on the working directory by default
and looks for all files tracked by the working directory and greps on them



$ hg init a
$ cd a
$ echo "some text">>file1
$ hg add file1
$ hg commit -m "adds file1"
$ hg mv file1 file2
$ hg grep "some"
file2:1:some text
file1:0:some text

This behaviour is undesirable since file1 is not in the current history and was
renamed as file2, so the second result was redundant and confusing


$ hg init a
$ cd a
$ echo "some text">>file1
$ hg add file1
$ hg commit -m "adds file1"
$ hg mv file1 file2
$ hg grep "some"

file2:2147483647:some text


The change can be seen in the line of the respective snippets, in the second case file1 is no more present in the repo and so is not searched again.


Link to the Differential Revision::

I then wrote the test demonstrating the same, next I plan to enable passing revs and multiple revisions to grep.

GSoC Blog Post #4

Another Fortnight gone by, and perhaps this was the time when we got most work done.

This time around I added two new features to mercurial.

They are: The allfiles mode

This would work on a single revision and get all the files that were
there in that revision. So it’s like grepping on a previous state.
Using this with wdir() :: hg grep -r "wdir()" --allfiles is what the
default behaviour is desired for grep.

Link to PR :


Then I also added the diff mode: This is a duplicate of the exisitng all flag. Since --all searches diffs, there diff is a better name for it.
The --all flag is still here for backward compatibility reasons.


Link to PR :


I am working on two more patches right now, will be posting about that in the next blog.

GSoC Blog Post 3

These two weeks I was involved in fixing the `–wdir()`. Yuya had asked me to not create an entire separate if/else block as that might lead to untested code paths.

So I was trying to work out another way. While I was trying to figure out a way to do this I realised the code had changed a bit since my last patch, and it nows throws WdirUnsupported exception. This made my life a bit easier.

After consulting Yuya Nishihara, I caught all the WdirUnsupported exceptions and then treated the changeset objects, file node objects differently that would work.

The patch to this can be found at

Currently, I am working on adding a mode to grep on unmodified files in a changeset.

More on this on my next post, stay tuned.

Proposal acceptance and community bonding period

Two weeks into the summer break and the gsoc coding period is about to begin.

It all started in February when I started looking for organisations to contribute for the Google Summer of Code 2018. I knew the language was going to be Python, so straight I was into the PSF Sub Orgs. The next challenge was to select the sub org, I thought of going for core software development and not some specialised field. And what better than a Version Control System.

So now with the org finalised, I started with browsing through the codebase. The huge codebase was intimidating at first. Having written only programs, diving straight into a software’s codebase was daunting. It was then I posted in the #mercurial on freenode that I was having this problem, and believe me that was the best thing that I did. Help came from a handle named JordiGH who pointed me to pudb, a graphical debugger that runs in the terminal. Little did I know that Jordi would eventually be mentoring me for the GSoC project. This was got me going, I could now run through the codebase the way I want, see the flow, see the function calls, see the object instantiations and it made my life a lot easier.

So there I was starting with issues. I started with a documentation fix. Then slowly moving into the core codebase. Honestly, I wasn’t expecting that the doc fix would have such a long discussion on the channel, it taught me to think from a different angle and how the community would react to the change.
Then I got into adding features to histedit which would incorporate revsets in their rule editor, I was really happy with this feature that I had added because this was a problem that I faced, even my fellow gsocer from mercurial felt it’s needed. I then tried adding support for multiline commit messages from the command line itself, which is there in Git but was missing mercurial, but my implementation wasn’t actually great and it got rejected. Next, I worked on an issue involving multiple carriage returns in hg annotate, I created a patch, but Yuya Nishihara had already solved this issue in a better way, so I just held that patch back.

Then as projects were announced, I chose to go with fixing grep’s behaviour in mercurial. This was a thing that the community was really interested. I started the documentation on this project. And made two significant contributions, while one fixed a five-year-old issue with grep, other which is still in progress is suppose to make hg work the way people would expect it to be.
Some of the merges came real close to the proposal submission deadline, and thanks to them my proposal looked better.
Here is a link my proposal :

Came April 23rd as I was a bit anxious. I didn’t even check the results, it was through my friends that I got to know that I was selected. It really thrills me to know that the code that I have written / would be writing would be used by people all over the globe, at organisations such as Mozilla and Facebook.

It was my exams time and followed by vacations, I interacted with my mentor twice during this period. These were brief.
During these first two weeks, I was mostly travelling and went to my hometown as I would get busy once the coding period starts.
Now that I am back, it’s time to get back to work.