navaneethsuresh's Blog

Coding period: week #12

navaneethsuresh
Published: 08/18/2019

This is going to be a blog post about fixing an urgent bug and splitting an old RFC patch of mine into stack to be landed. Also, finishing up something I was working for a long time.

 

What did I do this week?

My mentor introduced me to an issue[1] which is an urgent bug to get fixed. While pushing bookmarks, the bookmarks pointing to secret changesets are also pushed, but the changesets are not pushed. So, while pulling the bookmarks, the changeset it is pointing to will be unknown. We wanted to abort on pushing bookmarks which points to secret changes. I sent two patches. One[2] which demonstrates the issue which has tests and the other[3] one which fixes the issue. I also sent a patch[4] to abort on using both `--interactive` and `--keep` together with `unshelve` which got merged. I worked on two patches[5][6] to enhance the config registrar and its usage. Then, there was an old RFC patch[7] which introduces the first prototype of storing/restoring mergestate with `shelve`. I had to split that into a stack[8][9][10][11] to change its priority from RFC to patches which can be landed in code.

 

What is coming up next?

My mentor has requested some follow-ups to some of the merged patches. I shall be working on them. Also, I will be addressing the reviews to the WIP patches that are active now and cleanup the work. Then, I'll work on documentation of the work I did and the importance of that.

 

Did you get stuck anywhere?

Yes. While adding an abort on trying to exchange bookmarks which points to secret changesets, I was unable to solve a test case initially. My mentor asked me to sent a patch to the bitbucket and I did that. He gave me reviews there and it was later fixed by me and I sent the patch to the core.

View Blog Post

Coding period: week #11

navaneethsuresh
Published: 08/11/2019

This is going to be a blog post about cleaning up things I did until now.

 

What did I do this week?

Last week, I worked on adding a template keyword called `defaultvalue` to store the default value of a registered config item. Also, I did work on adding `--registered` flag to `hg showconfig` command to show all the registered config items. In this week, I got more reviews on it and I had to fix it. So, I sent the following patches and some of them got merged.

[1]: D6709 config: add --registered flag to show all known configs

[2]: D6699 unshelve: abort on using --keep and --interactive together

[3]: D6712 config: remove pycompat.bytestr() for defaultvalue

[4]: D6720 config: fix fm.data() handling of defaultvalue

 

 

What is coming up next?

I was trying to add logic for the use of `--interactive` with `--keep` for `hg unshelve`. My mentor Pulkit suggested me to store the remaining shelved change with a new basename on using these flags together. I have coded up this feature. But, unfortunately, my regression tests are not running as expected while this is working fine when I locally built it and tested on another mercurial repo. I will try to fix these tests. Also, I'll be working on changing the default behavior of `hg grep` to the expected behavior which is hidden under a config option.

 

Did you get stuck anywhere?

Yes. While working on adding support for `hg unshelve --interactive --keep` for a partial unshelve, I couldn't get my regression tests running. I am still working on this to find a solution for this.

View Blog Post

Coding period: week #10

navaneethsuresh
Published: 08/03/2019

This is going to be a blog post about coding up a much requested feature by the community.

 

What did I do this week?

This week my mentor asked me to work on an interesting feature which was requested by the community. The issue can be found here[1]. I have sent three patches to Phabricator in which two of them have been merged. You can find the patches here:

[2]: D6709 config: add --all flag to show all known configs

[3]: D6712 config: fix defaultvalue template keyword

[4]: D6704 config: add defaultvalue template keyword

Mercurial has a command called `showconfig` which by default without any flags shows all the config items as set by the hgrc. But, I had to add a flag to show all config items in the config registrar. So, I added an `--all` flag to show all known config items. Also, I added a new template keyword called `defaultvalue` to show the default value of the config item. Until now, nothing was shown on trying to see a default value of a config item which has not set a value by the user. Community was much interested in this and Yuja had suggested the UX. For the `--all` flag to work, I had to walk in such a way that I am digging up the registrar other than just user config options. I had to skip the items which had dynamic default values.

 

What is coming up next?

I haven't decided upon the exact feature on work on next week. My mentor asked me to select one of either the bug tracker or the WeShouldDoThat page depending upon the community interest.

 

Did you get stuck anywhere?

I had a starting trouble to find out a way to access the items from the config registrar. Then, my mentor Pulkit told me about a variable called `self._knownconfigs`. That was a turning point. The rest of the task happened really fast.

View Blog Post

Coding period: week #9

navaneethsuresh
Published: 07/27/2019

This is a blog post about trying to clean up the code that I have written for a feature that had merged and marked as experimental.

 

What did I do this week?

For the past few weeks, I have been working on an interesting feature called `unshelve --continue`. My mentor was actively giving reviews on the old patch even after getting that merged. So, I had to send a follow-up stack following the merged patch. I started with a patch[1] to modify the help text on verbose mode to say the user why this feature is still experimental and it's problems. Then, I sent a new stack:

[2]: D6679 unshelve: store information about interactive mode in shelvedstate

[3]: D6687 unshelve: create a matcher only if required on creating unshelve ctx

[4]: D6694 unshelve: fix bug on a partial unshelve with --continue

[5]: D6697 cmdutil: add allowunfinished to prevent checkunfinished() on docommit()

[6]: D6685 unshelve: changes how date is set on interactive mode

[7]: D6686 unshelve: handle stripping changesets on interactive mode

[8]: D6683 unshelve: unify logic around creating an unshelve changeset

[9]: D6699 tests: add test for unshelve --interactive --keep

 

What is coming up next?

Since I have been working on `unshelve --interactive` for a long time, my priority should be this only. I will try to clean the code and modify the tests to account for all cases possible. If that is getting over on time, I will work on an interesting issue[10].

 

Did you get stuck anywhere?

As usual, I got problems in rebasing and evolving changesets, I had to make the DAG linear after every time after resolving enormous conflicts. But, I got used to it and it wasn't much a problem per se.

View Blog Post

Coding period: week #8

navaneethsuresh
Published: 07/21/2019

This is a blog post about unfortunately getting a bug in the feature I thought I had written properly and fixing that.

 

What did I do this week?

I have been working on adding an interactive mode to unshelve for a really long time. It was not easy like I had thought. My mentor reminded me that my code won't work for unshelve which can lead to conflicts. So, I had to modify a function called `shelvecontinue()` to work on interactive mode. unshelve with conflicts is aborted and user had to do `hg unshelve --continue` to continue the unshelve after conflict resolution. I had to modify the function `shelvecontinue()` and the main function `dounshelve()`. It took me enough time to modify both the functions and to get the tests running successfully. Later, the patch[1] got merged. But, then my mentor informed me that I had to mark this feature as `EXPERIMENTAL` as unshelve interactive logic completely lies on `_rebaserestorecommit()` which will do a graft. So, the user will get conflicts even if there are conflicts in the changes other than those requested by the user. I sent two[2][3] follow up patches for simple fixes and those got merged. But, now working on the main fix.

 

What is coming up next?

I am trying to modify `_rebaserestorecommit()` so that when there are conflicts, the user should only get conflicts when there are only conflicts in the changes which are requested by the user. This may take time.

 

Did you get stuck anywhere?

Yes. While trying to modify `_rebaserestorecommit()` function so that there should be conflicts only when there are conflicts on changes requested by the user, I couldn't get this to work. `cmdutil.dorecord()` cannot be called directly. Since we are already committing the changes as `shelvectx` and not doing anything, we need to rethink how to interactively select changes from a stored commit. Now, we are doing a graft and changes are there in the repo. So, `cmdutil.dorecord()` will work successfully. I haven't got a solution for this till now. Will work the next week on this.

View Blog Post