resolve: confirm functionality | history-editing-backup config option for amend, rebase

In last week, I worked on adding 1) confirm option for resolve command 2) support for history-editing-backup config options in commands “amend” and “rebase”.

  • Patches for confirm functionality in resolve:

resolve: support commands.resolve.confirm option with –mark flag

resolve: add confirm config option

  • Patches for history-editing-backup config option:

rebase: support “history-editing-backup” config option

rebase: move “backup” flag to rebaseruntime

amend: support “history-editing-backup” config option

–confirm option for rebase and nobackup config option for history editing commands

In last two weeks, I worked on adding:

  •  confirm option for rebase:

This option gives a functionality to confirm before finishing rebase so if we hit a conflict then it will simply abort and if rebase is successful then it will ask user to apply changes by prompting “apply changes (yn)?”


rebase: add –confirm option

rebase: make sure we don’t loose the return code in –confirm option

rebase: correct misleading message in –confirm option

rebase: in –confirm option just abort if hit a conflict

rebase: remove unnecessary confirm block

  • history-editing-backup config option

This config option aims to give a functionality to not store any backup for history editing commands like histedit, rebase, amend etc. Currently it support histedit only and I am working to add this in other commands also.

To enable this config add following lines in you .hgrc config file:


history-editing-backup = False


histedit: add history-editing-backup config option

histedit: drop –no-backup option


Refactoring/Improving dryrun for rebase

Last week was all about refactoring through the dryrun implementation of rebase, like:

  1. Extracted dryrun as a separate function _dryrunrebase()
  2. No backup is stored during dryrun
  3. Improved output by suppressing some unnecessary warnings
  4. Some other little changes


Now, remaining work is to add –confirm option in rebase ( for which I have already sent a merge request) and one more idea on which I’m currently working, is to show the diff of a file section where we hit a conflict (when –verbose is passed)

And I also added –no-backup option in histedit:

histedit: add –no-backup option (issue5825)


rebase: added dry-run functionality

Well, last week I started to work on adding dry-run functionality in rebase. And as my mentor suggested that we could use IMM (In-memory merge) for implementing dry-run for rebase, so I had a meeting with my mentor Sean and it was very helpful for me. Initial patch for this dry-run functionality has been pushed-in:

rebase: add dry-run functionality

But still there is some work to do in dry-run for rebase like improving output and some automation, formatter work for which I still have to discuss with my mentor. And one more suggested idea is to add –verbose mode which will show the diff of two conflicting files.

To give you some insight of IMM, we don’t actually update working directory to the destination at the time of merging a node, instead we take an overlay of working_ctx and merge that node in overlayworkingctx in-memory and see if we hit a conflict or not. If successful then we flush that resulting ctx on disk. There is still some work is going on in this In-Memory Merge implementation and I think one goal is to flush all the rebased csets at once at the end of this merge process (after we rebased all the csets in-memory).

And I think there is still more areas in IMM, I should take a look on, to get complete insight of it’s structure and working :`)

FYI, Sean is refactoring though all this IMM implementation and also aiming to remove that overlayworkingctx() and make memctx() to do all this work at one place.


graft; phase; 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


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.

phase: add dry-run functionality


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.