hg git Rosetta Stone
Git hg rosetta stone at github.com
Table of similar commands
add the specified files on the next commit
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.
show changeset information by line for each file
backup workspace changes and metadata
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.
commit the specified files or all outstanding changes.
Creates only a local change set.
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.
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>
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 ...".
show a list of change sets that would be pulled.
git fetch <remote> && git whatchanged ..<remote>/branch
create a new repository in the given directory
list active files
git diff --name-only <commits>
show revision history of entire repository
merge working directory with another revision
git merge/git pull
check for stylistic nits in active files
show a list of change sets that would be pushed.
show changes between ...
run pre-integration checks on this workspace
diff workspace against its parent
git diff <other branch>..
pull changes from the specified source
git fetch / git pull
push changes to the specified destination
diff of the current patch and subsequent modifications
create a new patch
pop the current patch off the stack
push the next patch onto the stack
update the current patch
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.
remove the specified files on the next commit
restore workspace from backup
start stand-alone webserver
show changed files in the working directory
|hg strip $ID||remove change set $ID and update working files to the preceeding change set.|
summarize working directory state
update working directory (or switch revisions)
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
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.
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.