GSoC Blog post #7

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

The PR can be found at https://phab.mercurial-scm.org/D3976

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: https://phab.mercurial-scm.org/D3919

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 https://bitbucket.org/sangeet259/mercurial-scm/commits/e0c1548a16e1b47effdbab14a1856122ad39cd57

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

==========================Demonstration================

OLD BEHAVIOUR

$ 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

NEW BEHAVIOUR

$ 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:: https://phab.mercurial-scm.org/D3826

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 : https://phab.mercurial-scm.org/D3728

 

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 : https://phab.mercurial-scm.org/D3763

 

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 https://phab.mercurial-scm.org/D3673.

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.

GSoC Blog Post #2

So it is two weeks into the coding period and I thankfully haven’t fallen much behind my own set timeline.

The tasks that I had set this week were fixing the--all flag and fix the working directory grep. Thankfully I had done major of this work during/after submission. The fix of the --all was tested and merged and is a part of the stable version of hg now.

Here is the issue it fixed with grep : https://bz.mercurial-scm.org/show_bug.cgi?id=3885

Here is the link to my revision that is merged : https://www.mercurial-scm.org/repo/hg/rev/a2a6755a3def

The best part of the issue was that fixing it took just changing two lines. The point is that it’s not the number of lines you that matter, it’s the impact that the code has. I must admit that I might have just got this accidentally. And this is the beauty of open source, that issue was open for five years and was one of the bottlenecks of my GSoC project. This reminds me of a quote (Linus Law) “Given enough eyeballs, all bugs are shallow”.

I wrote a detailed blog on this subject you can read more about it :

http://sangeetmishra.me/2018/03/26/demonstrating-the-problem-with-forward-ordered-grep-all-in-mercurial.html

I had a video chat with my mentors Jordi and Pulkit. We discussed how to go ahead and work on the remaining of the Grep Plan. Jordi pointed out that making grep accept revision ranges and work on the working directory might be challenging. He assigned me this task till the first evaluations.

I already have a patch in the working directory, but there is a lot of scope for improvement on that, I am working currently on making it support the argumentwdir() in the -r flag.

The way I plan to do is catch it as an exception and handle it separately. This was concluded by a discussion with Yuya Nishihara. There are still other problems that I think may lay ahead. I am also having some doubts lately which I had been asking on the #mercurial, and have got suggestions from the community.

In short, the first two weeks as Google Summer of Code student has been great. Looking forward to the upcoming weeks and more commits.

Edit: Here is the link to the patch that I have sent and is currently working on :

Yuya has reviewed and given this comments :

This patch appears to do 3 separate things by adding a big “if” branch.

  • * fix grep -r 'wdir()'
  • * add mode to include unmodified files
  • * change the default
  • It’s probably better to write one (or more) patches for each change, in a way not duplicating code for each combination of possible options.

So I am currently working on breaking into separate patches handling the three things separately!

 

 

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 : bit.ly/gsocprop

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.