Coding period: week #2

Published: 06/07/2019

This is a blog post about how I spent this week implementing the main feature offered by the project with a simple hack.


What did I do this week?

I worked on adding a new flag `--unresolved` to both `hg shelve` and `hg unshelve` commands and have sent two PRs[1][2] to the core with an initial prototype of the project implementation. This changes the behavior of `hg shelve` and `hg unshelve` commands to handle unresolved merge-states. I have also written test cases and error handling for all corner cases possible. At first, I worked on my bitbucket clone of `hg` and was consistently pushing new changesets and seeking reviews from my mentor. After getting a nice prototype, I sent those two patches to Phabricator. This will slightly change the behavior of these commands in both UI and internal workflow. The user has to update to one of the merge parents of the unresolved shelve to unshelve for later. I tried to fix this internally. But, couldn't find out a solution. Things can get worse when I have to write traversal mechanism and write enough parsing. This may slow down hg. So, a perfect balance between performance and intuitive nature can be maintained. Since, `hg log -G` command can perfectly help the user to get the old merge parents, it's no big deal to update to one of those just before doing unshelve.


What is coming up next?

Now that I have written the UI of the project and got that to work. But, to reach the end-goal of the project I would have to store data in a more convenient way. In the current implementation, I made use of the already stored data about merge-state. I will wait some more time for reviews from the community. Until now, all of the reviews I have got were from my mentor only. So, the next step will depend upon community's interest of getting things done in a usual manner. I will try sending patches about storing data in changeset level.


Did you get stuck anywhere?

I haven't had an idea that a simple hack can make the project work. I tried to store unnecessary data in my implementation. Then, my mentor told me we are already storing these things in a different way and I can make use of that. I interacted with my mentor very much and got enough confidence to push new changesets consistently and make things work. Surprisingly, I stuck at a point of sending patches and got an error that my hg version was not compatible. But, it got resolved automatically. I had already contributed much to the core. Still couldn't figure out why it has happened. Also, my initial implementation modified the code of more commands. At that time, my mentor told me that we can skip modifying things at such a low level if I write a neat abstraction at the top level. And at last, I successfully isolated my code from other parts of the codebase and wrote enough comments on that to make the community more understand my code.