Skip to end of metadata
Go to start of metadata

hg git Rosetta Stone

Git hg rosetta stone at

Table of similar commands

hg command

hg description

git command

git description

hg add

add the specified files on the next commit

git add

Add file contents to the git index.

Note that "git add" is really NOT the same as "hg add", only similar.  See the Other differences section for details.

hg annotate

show changeset information by line for each file

git blame


hg backup

backup workspace changes and metadata



hg clone

Make a copy of an existing repository.

Note that with hg, this copies everything from the parent, including all branches, and gives you a working copy of the default branch.

git clone


hg commit

commit the specified files or all outstanding changes.

Creates only a local change set.

git commit

Create a change set from the contents to the git index.

Note that "git commit" is really NOT the same as "hg commit", only similar.  See the Other differences section for details.

hg diff

diff repository (or selected files)

git diff / git diff --cached

Show differences between working files and the git index,
or ...

Note that "git diff" is really NOT the same as "hg diff", only similar.  See the Other differences section for details.

hg export $ID

Dump the header and diffs for one or more changesets.

This produces a file that entirely captures the contents of the change set specififed by $ID.  The resulting file is used with "hg import".  (This is often useful for transporting changes between different workspaces and/or branches, etc.)

git format-patch <commits>


hg forget

forget the specified files on the next commit

git reset <paths> / git checkout – <paths>


hg importcreate a change set from a file that was created using "hg export".  The import preserves the full committer information, change description, date, etc.

git am <file>

But note, the file needs to be in the form created by "git format-patch ...".
If you have a file from "hg export", you'll need to edit the header, or apply the "hg export" using "patch" and then use "git commit" (with options) to recreate the change set descripion.


hg incoming

show a list of change sets that would be pulled.
(with -v, also show list of files in each)

git fetch <remote> && git whatchanged ..<remote>/branch


hg init

create a new repository in the given directory

git init


hg list

list active files
(those changed in this workspace)

git diff --name-only <commits>


hg log
hg log FILE 

show revision history of entire repository
show revision history of specified file

git log


hg merge

merge working directory with another revision

git merge/git pull


hg nits

check for stylistic nits in active files
(onbld extension)

git nits


hg outgoing

show a list of change sets that would be pushed.
(with -v, also show list of files in each)

git whatchanged

show changes between ...

hg pbchk

run pre-integration checks on this workspace
(onbld extension)

git pbchk


hg pdiffs

diff workspace against its parent
(onbld extension)

git diff <other branch>..


hg pull

pull changes from the specified source
("pull -u" to update as well)

git fetch / git pull


hg push

push changes to the specified destination

git push


hg qdiff

diff of the current patch and subsequent modifications
(mq extension)



hg qnew

create a new patch
(mq extension)



hg qpop

pop the current patch off the stack
(mq extension)



hg qpush

push the next patch onto the stack
(mq extension)



hg qrefresh

update the current patch
(mq extension)



hg recommit

replace outgoing changesets with a single equivalent changeset
(onbld extension)

git rebase -i

This will bring up a "control" file in your editor, with typically two or more lines starting with "pick" and a revision hash.  You typically change the second (and later) lines from "pick" to "squash", then save/quit.  Afterward, you should see just one change set, containing all your changes.

As the man page warns, don't do this if you have "down stream" (child) repositories that may want to pull from this one.


hg remove

remove the specified files on the next commit

git rm


hg restore

restore workspace from backup



hg serve

start stand-alone webserver



hg status

show changed files in the working directory
(One letter prefixes like the old cvs status)

git status


hg strip $IDremove change set $ID and update working files to the preceeding change set.  

hg summary

summarize working directory state



hg update

update working directory (or switch revisions)
updates local working copy from local repo.

git checkout



creates an input file for webrev(1) that references the change set ID for the parent, and lists all the modified files.

Usage:hg-active -w `pwd` > Active.txt webrev -w Active.txt

Not available separately to webrev


edit .hg/cdm/*.NOT

Exception files for "hg nits", etc.

cddlchk.NOT, copyright.NOT, cstyle.NOT, ...

Add file names to these files to cause "hg nits" to skip the (possibly lengthy) noise about them.



Other differences

The git index

Mercurial users coming to git will need to understand the concept of the git index.  In mercurial, when you do "hg commit",  the content you commit is always what you see in your current workspace files.  This is simple for a user, and not surprising for people coming from other source code management systems like cvs, etc.  However, git does NOT work this way.  Instead, when you "git commit", the content that goes into the commit is NOT (necessarily) what you see in your working files.  (Note, git users consider this a feature, not a bug.)  Instead, "git commit" creates a change set from that content you have "added" to the "index".   So "what's this 'index'?" you ask.  The git "index" is a sort of "staging area" for your changes.  You update the index using "git add" - and this is where "git add" is really not so much like "hg add";  In git, you must "git add" every time you make new changes in your working files that you want included in the "index" (staging area).  By contrast, you "hg add" just once per changed file, and mercurial tracks changes in such files.