graft | phase| meeting ;) | dryrun for rebase

First, let’s just talk about my last week contributions:

I sent a patch for adding –no-commit mode in graft command ( graft is to copy changes from other branches) in the end of Feb but it was blocked because of some work going on to change the statefile format (statefiles are for storing the current state of a running command when we hit a conflict, so that we can continue from the same state after conflict is resolved) and before one week that work is completed. (Actually for this change a thirdparty library cbor2 is used which makes it easy to store the data as a “key:value” format. It serialize the data as a bytestring and deserialize as a dictionary object using methods “dumps/loads”. Before cbor2 we are just simply writing the state directly to the statefiles and was not using any encoding/decoding of the data.

So now, as new format for statefiles is added, I updated my patch which is now using the new format.

Meeting 🙂

And coming to my “mercurial phases” work, it is almost completed. Last week I had a meeting with my mentor Pulkit and he suggested me not to put so much efforts on “phases” so we decided, instead of showing the range of changesets whose phase are changed or could be changed, we will simply return a list of those changesets.

These are the patches which add –dry-run functionality to mercurial phase command:

After that coming to my next task, Pulkit suggested me to work on “–dry-run for rebase”. He told me that in rebase we have an optional mode called “in-memory” where we are using IMM (in-memory merge) concept, in this mode we don’t actually update the working directory and write changes in-memory and apply them in last if everything is fine. IMM has some benefits like it save checkout time as we don’t have to update the working directory and we are able to check if two csets will conflict or not. So he said ” we can use this concept in –dry-run for rebase”

Before this meeting I was thinking to work on adding –dry-run for pull and push but we have something similar for this, called incoming and outgoing. Hmmmm, and most probably my next post would be about the working of IMM and how I’m gonna complete my next task : “Add –dry-run functionality in rebase

Thanks for reading 🙂

mercurial phases

Hello again!

Now I’m working on adding dry-run for mercurial phases. If you use mercurial, you would probably know what phases are, but for those who don’t know, let me tell you a little bit about phases:

What are phases?

Please keep in mind that changeset/cset/commit are almost same things. In mercurial, this feature named phases keeps track of which cset should be shared. And it is decided on the basis of what is the phase of that cset.

Each  cset in a repository is in one of the following phase:

  • public – cset is visible on a public server
  • draft – cset is not yet published
  • secret – cset should not be pushed, pulled or cloned

And following is the order of phases and no cset can be in a lower phase than its ancestors:

public < draft < secret

If you want to know more about phases:

Implementation and Dry-run:

Coming to my work, I have to add dry-run functionality to phases. And first time when I saw implementation of phases and how internally phases works, it was interesting to know that mercurial don’t store phase value for each cset infact it only store phaseroots (roots of phases DAG in you history log) and use these phaseroots for every calculation related to phases. Before you go ahead you should know how to use phase command, if  you don’t, then first read about this.

The expected result from dry-run is to show that what would be the result of phase commands (I will show you) if we run the commands without dry-run, like:

hg phase –draft -r revs –dry-run


f7b1eb17ad24 : : 14b465a7e25b   secret -> draft

cannot move 2 changesets to a higher phase, use –force

Result showed the range of those revisions whose phases can be changed to draft (csets which are in secret phase) and message to tell user to use –force for rejected csets(which are in public phase).

Following is the link to my work, for now it’s just print all nodes and my remaining work is to show range instead of showing all the nodes.

What dry-run functionality would do?

Hello, world! 🙂

I am Sushil khanchi from India. And I am very excited about upcoming summer with a hope of learning a lot from GSoC. Let me tell you what I will be doing during this time period. As the title says Dry-run functionality to each write command in Mercurial”, so what exactly  Dry-run means:

In mercurial, we have some write commands with  –dry-run flag that turns on a mode in which user will get to know what will be the result output, without actually running that command. The focus of this project is to add dry-run functionality to each write command those are a good candidate at present. Some of the good candidates are phase, strip, pull, push, amend, graft, merge, rebase, histedit and unshelve. In case of rebase, histedit and graft prints out the graph that would result if we ran the command.

These are my present contributions

Thanks everyone, for giving me such a great opportunity.