Editor for mercurial

Last evening one of  my co-worker was sitting beside me, as I was pushing in some changes into the  project repository. And as I hit the "hg commit" command my "gvim" editor popes up for writing the commit message, and this buddy of mine sitting besides me asks me how did do you do that, howcome your gvim pops up whereas on my computer the same command opens a vi editor in the same terminal. I was like its easy,  I set the editor up in the Mercurial config file the famous ".hgrc" file.
Then he goes no, thats not the case because I have copied over your ".hgrc" file long back and if it was that file, then it would have been happening for me as well. I was like hmm let me see what I did. Then I realized that I have the UBUNTU environment variable EDITOR set for me to "/usr/bin/gvim  -f" ......that explains everything.


For making proper sense out of what I mean by above incidence, read the following explanation :

Mercurial tries to pick which program to call to edit a commit message by trying the following (in order):

1. HGEDITOR environment variable
2. editor configuration option in [ui] section (in hgrc or passed with --config ui.editor command-line option).
3. VISUAL environment variable
4. EDITOR environment variable
5. vi, if none of the above is set
   
   
   So the above explanation suggests that I was actually using option 4 above, but I thought I was using option 2 while I explained to the co-worker 
   and on the hind side now its clear that my co-worker was using was option 5.  
   
   

Mercurial Strip

Yesterday evening in was in a bit of a fix at work, I was working on a new feature-name mercurial branch and and committed a few things into the branch and posted the changes onto a review system we have at work. after the team reviewed my changes it was time to push them over and merge it with the main "DEFAULT" branch.

So I started and did as follows:

hg st

Should show no modified files.

Make sure your working copy is based on the branch:

hg branch

It should report the name of the feature branch. 

hg update feature-name

Close out the branch if it's a Feature Branch

hg commit --close-branch -m "closed branch feature-name"

Update working copy to be based off of the default branch instead of the branch:

hg update default

Merge from the branch to default (assuming feature-name is the name of the branch you are merging to default):

hg merge feature-name

When everything looks good, commit the merge 

hg commit -m "merged feature-name branch to default"

and at last push the merge onto default.

I did the above step by step but then at last the "hg push" aborted with an error, So now what to do.

I looked back and realize that I didnt push the changes into the feature barnch (though committed them), but now have so many change sets and I am on Default branch now.




I update back to my feture branch and want to be at the same change set where I started so here comes "hg strip" to my rescue, though there can other solution too, I used hg strip to strip off all the change set and start over merging into default again.




Okay so now What is that hg strip command do...here is brief explanation below:

hg strip rev removes the rev revision and all its descendants from a repository. To remove an unwanted branch, you would specify the first revision specific to that branch. By default, hg strip will place a backup in the .hg/strip-backup/ directory. If strip turned out to be a bad idea, you can restore with hg unbundle .hg/strip-backup/filename.

If others revision in the repository have higher number than the stripped one, those one are renumbered in order to keep a sequential numbering scheme. The hash remains the same.