[ACCEPTED]-Git equivalents of most common Mercurial commands?-mercurial

The Git-HG rosetta stone is not bad

There are a few other gotchas between the 24 two not mentioned there. This list was cribbed 23 from my own blog post when I went the other 22 way (git -> hg).

Hg .hgignore, syntax: glob is the 21 same behaviour as git's .gitignore.

Git .git/config, ~/.gitconfig, use 20 git-config to modify the values
Hg .hg/hgrc, ~/.hgrc, use 19 hg help -c config

Git git commit -v<br> Hg hg diff | less; hg commit

Git gitk<br> Hg hg view, or thg from [TortoiseHg][1]

Git git gui<br> Hg Mercurial doesn't ship GUI to select 18 changesets, only console hg record command.

Git git rebase<br> Hg hg rebase. For 17 git rebase --interactive there's hg histedit, or Mercurial Queues

Git git push URL ; git remote add origin URL<br> Hg hg push URL; $EDITOR .hg/hgrc ; [paths] default = URL

Git gitk, git log origin/master..HEAD<br> Hg hg outgoing

Git git format-patch RANGE<br> Hg hg email -m filename -o

Git git add . ; Note 16 the dot
Hg hg add ; No dot needed.

Git git checkout REVISION-KEY<br> Hg hg update CHANGESET

Just to fill 15 the blanks, some of the most useful commands 14 from Mercurial:

Hg hg record
Git git add -p; git commit

Hg hg inc [URL]
Git No real 13 equivalent. You can only do equivalent of 12 hg pull; hg log -r .:

Hg hg out URL
Git Please add if you know how.

For merge 11 conflict resolution, the hg resolve command in Mercurial 10 has a few options that change the behaviour:

Hg hg resolve -m FILE (marks 9 the file as having been resolved by manually 8 fixing up the conflict problem)
Git git add FILE

Hg hg resolve -u FILE marks 7 the file as having been unresolved
Git git reset HEAD FILE to 6 unstage the file

Hg hg resolve -l (lists files with resolved/unresolved 5 conflicts)
Git git status - files that merged cleanly 4 are added to the index automatically, those 3 that are not have conflicts

Hg hg resolve FILE (after a merge, attempts 2 to re-merge the file)
Git no equivalent for 1 re-merging that I know of.

Note: one of the biggest difference between 91 Git and Mercurial is the explicit presence 90 of the index or staging area.

From Mercurial for Git User:

Git is the only DistributedSCM that 89 exposes the concept of index or staging 88 area. The others may implement and hide 87 it, but in no other case the user is aware 86 nor has to deal with it.

Mercurial's rough 85 equivalent is the DirState, which controls working 84 copy status information to determine the 83 files to be included in the next commit. But 82 in any case, this file is handled automatically.
Additionally, it 81 is possible to be more selective at commit 80 time either by specifying the files you 79 want to commit on the command line or by 78 using the RecordExtension.

If you felt uncomfortable dealing 77 with the index, you are switching for the 76 better ;-)

The trick is, you really need 75 to understand the index to exploit fully 74 Git. As this article from May 2006 reminds us then (and it is 73 still true now):

“If you deny the Index, you 72 really deny git itself.”

Now, that article 71 contains many commands which are now simpler 70 to use (so do not rely on its content too 69 much ;) ), but the general idea remains:

You 68 are working on a new feature and starts 67 to make minor modifications on a file.

# working, add a few lines
$ git add myFile
# working, another minor modification
$ git add myFile

At 66 this point, your next commit will embark 65 2 minor modifications in the current branch

# working, making major modification for the new features
# ... damn! I cannot commit all this in the current branch: nothing would work

$ git commit

Only 64 records the changes added to the staging 63 area (index) at this point, not the major 62 changes currently visible in your working 61 directory.

$ git branch newFeature_Branch
$ git add myFile

The next commit will record all 60 the other major changes in the new branch 59 'newFrature_Branch'.

Now, adding interactively 58 or even splitting a commit are features 57 available with Mercurial, through the 'hg record' command 56 or other extensions: you will need to install 55 RecordExtension, or the CrecordExtension.
But this is not part of the normal 54 workflow for Mercurial.

Git views a commit 53 as a series of "file content changes", and 52 let you add those changes one at a time.
You 51 should study that feature and its consequences: Most 50 of Git power (like the ability to easily 49 revert a merge (or bisect the problem, or revert a commit), contrary to Mercurial) comes from that "file content" paradigm.

tonfa (in 48 in profile: "Hg dev, pythonist": figures...) chimed 47 in, in the comments:

There's nothing fundamentally 46 "git-ish" in the index, hg could 45 use an index if it was deemed valuable, in 44 fact mq or shelve already do part of that.

Oh boy. Here 43 we go again.

First, I am not here to make 42 one tool looks better than another. I find 41 Hg great, very intuitive, with a good support 40 (especially on Windows, my main platform, although 39 I work on Linux and Solaris8 or 10 too).

The 38 index is actually front and center in the 37 way Linus Torvalds works with a VCS:

Git used explicit index updates from 36 day 1, even before it did the first merge. It's 35 simply how I've always worked. I tend to 34 have dirty trees, with some random patch 33 in my tree that I do not want to commit, because 32 it's just a Makefile update for the next 31 version

Now the combination of the index (which is 30 not a notion seen only in Git), and the "content 29 is king" paradigm makes it pretty unique and "git-ish":

git is 28 a content tracker, and a file name has no meaning unless 27 associated to its content. Therefore, the 26 only sane behavior for git add filename 25 is to add the content of the file as well 24 as its name to the index.

Note: the "content", here, is defined as follows:

Git's 23 index is basically very much defined as

• sufficient to contain the total "content" of the tree (and this includes all metadata: the filename, the mode, and the file contents are all parts of the "content", and they are all meaningless on their own!)
• additional "stat" information to allow the obvious and trivial (but hugely important!) filesystem comparison optimizations.

So 22 you really should see the index as being the content.

The content is not the "file name" or the "file content" as separate parts. You really cannot separate the two.
Filenames on their 21 own make no sense (they have to have file 20 content too), and file content on its own 19 is similarly senseless (you have to know 18 how to reach it).

What I'm trying to say 17 is that git fundamentally doesn't allow you to 16 see a filename without its content. The 15 whole notion is insane and not valid. It 14 has no relevance for "reality".

From 13 the FAQ, the main advantages are:

• commit with a fine granularity
• help you to keep an uncommited modification in your tree for a reasonably long time
• perform several small steps for one commit, checking what you did with git diff, and validating each small step with git add or git add -u.
• allows excellent management of merge conflicts: git diff --base, git diff --ours, git diff --theirs.
• allows git commit --amend to amend only the log message if the index hasn't been modified in the meantime

I personally think 12 this behavior shouldn't be the default, you 11 want people to commit something that is 10 tested or at least compiled

While you are 9 right in general (about the "tested 8 or compiled" part), the way Git allows 7 you for branching and merging (cherry-picking 6 or rebasing) allows you to commit as often 5 as you want in a temporary private branch 4 (pushed only to remote "backup" repository), while 3 re-doing those "ugly commits" on 2 a public branch, with all the right tests 1 in place.

Mercurial:

hg init . # start a project in the current directory
hg addremove # look for any added or deleted files
hg commit -m "comment" # commit any uncomitted changes
hg status # what have i changed since the last commit?

Git Equivalents:

git init
git add -A
git commit -am "comment" # -a is not necessary along with the above add -A
git status

0

It is roughly the same, without addremove:

git init # Start a project in the current directory
git status # Displays both changes and added/removed files
git commit -m "comment" # commit any uncommited changes

However, these 4 are commands you would use when working 3 alone. You get into the neat stuff when you 2 want to merge your changes with other people's 1 work with git pull and git push, and related commands.