hg git Rosetta Stone
Git hg rosetta stone at github.com
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, 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 import | create 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 ...". | |
hg incoming | show a list of change sets that would be pulled. | git fetch <remote> && git whatchanged ..<remote>/branch |
|
hg init | create a new repository in the given directory | git init |
|
hg list | list active files | git diff --name-only <commits> |
|
hg log | show revision history of entire repository | git log |
|
hg merge | merge working directory with another revision | git merge/git pull |
|
hg nits | check for stylistic nits in active files | git nits |
|
hg outgoing | show a list of change sets that would be pushed. | git whatchanged | show changes between ... |
hg pbchk | run pre-integration checks on this workspace | git pbchk |
|
hg pdiffs | diff workspace against its parent | git diff <other branch>.. |
|
hg pull | pull changes from the specified source | git fetch / git pull |
|
hg push | push changes to the specified destination | git push |
|
hg qdiff | diff of the current patch and subsequent modifications |
|
|
hg qnew | create a new patch |
|
|
hg qpop | pop the current patch off the stack |
|
|
hg qpush | push the next patch onto the stack |
|
|
hg qrefresh | update the current patch |
|
|
hg recommit | replace outgoing changesets with a single equivalent changeset | 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 | none |
|
hg status | show changed files in the working directory | git status |
|
| hg strip $ID | remove 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) | git checkout |
|
hg-active | 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. | ~/.git/*.NOT |
|
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.