This is going to be blog post about cleaning up the work I was doing and revisiting some old things I have done during the GSoC period.

What did I do this week?

I got a patch merged for adding `experimental` argument to the config registrar. But, reviewers asked me to send a compatibility fix as a follow-up as the extension `perf` was failing for older versions of Mercurial. So, I had sent a patch[1] about that and it got folded to the old merged patch by the reviewers. Also, I was asked some questions by my mentor on some of the patches in the stack of `--unresolved`. I investigated on them and answered. A couple of patches were stuck in the middle as I was not able to reproduce the test results in the bug description apparently. So, I investigated on that and updated the patches[2][3]. Then, I started documenting the things I have done during the whole summer as the final report of GSoC. You can read it here[4].

Did you get stuck anywhere?

I was stuck in reproducing the test results given in one of the bug descriptions. But, I found that it was due to a missing indentation. It might sound trivial but, it was not. This was later resolved and the patch was accepted by my mentor,

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.

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.

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.

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.