Delivering solid user friendly software solutions since the dawn of time.

Mercurial - Notes

Categories: Mercurial Notes

Mercurial - HG


  • Created by Matt Mackall at same time Git started.
  • DVCS written in Python
  • No partial commits (only atomic commits)
  • Three-way merging

Source control for tracking and sharing
Terms: Source, revision, version controlling
Types: Manual merging, File locking, Version merging
Architecture: Centralized, Distributed (no central server, appointed central server or lieutenants/commander)

Install TortoiseHg
Global settings
Username: firstname lastname <email address> (is mostly used as a convention)
Extensions: graphlog
-> updates the mercurial.ini file in each users root (c:/users/user/mercurial.ini)

hg help
hg init / hg ci (.hg folder is repository for all subfolders)
hg status
hg add
hg add foo.txt
hg commit (will prompt for change message, will commit all folders, emty folders will not be added !)
hg commit -m "your message" / hg ci -m "message"
hg log --limit 5 / hg -l 5 (will show last 5 changes)
hg glog

hg diff
hg revert --all
hg revert foo.txt (will create a copy of your discarded file in same folder with .orig extension)
hg revert foo.txt --no-backup

Ignore files for adding:

  • create .hgignore in root 
syntax: glob

syntax: regexp

You can only undo the most recent commit and when it has not yet been shared with another repository.
hg rollback

hg update 1 (locally: revision number of the changeset)
hg update e99fffee (globally: changeset identifier)

del foo.txt
hg remove foo.txt

Working with a server

md repository
hg init
hg serve (will run http server on localhost:8000)
cd .hg

  • create file hgrc

hg clone http://localhost:8000 hgclientfolder
hg push
hg out (compare local outgoing with server version)
hg incoming (compare local incoming from server)

Pulling changes from server, will update your local repository but not your working copy!
hg pull
hg update

Implicit branches
Created by a commit
Keep time of changes short


  • Can be used if we need to bugfix something quickly and we are in the middle of a development we can not yet check in.
  • Although multiple clones on one machine is not advised.
  • Fork if you want to create a new flavor and do not have the intention to commit back
  • Fork if you want to contribute on open source project, do all your changes and when finished you request a pull request to the main repository.

Named branches

  • we always start in default
  • branch name stored with changeset
  • mostly we create a branch for releases to other environments

hg update -r 6
hg branch
hg branches
hg identify -n
hg branch production (use bookmark feature if you want same branching strategy as git)
hg ci -m "quickfix"
hg update default

hg up branchtobeclosed
hg ci --close-branch -m"no longer needed"
hg up default

hg heads
hg up default (make sure you are in branch you want to merge to)
hg merge production
hg ci -m "merge"

hg parent (show the changeset that's in the working directory)
hg paths (shows a list of known remote repositories)
hg tag version-1.0 (marks the hex number of the changeset)
hg tag -r . Version-1.1
.hgtags sometimes needs merging too :)