Lately I'm playing with Mercurial (hg) and Git but I couldn't tell the difference between the two. Actually it is quite thin but noticable. Here's a comparison of hg vs git and my conclusion
Sorry for the format but these are notes I took while playing with hg and git. I 'm too lazy to format them in html ;)
# this comparison assume that you have
# a ~/.gitconfig and a ~/.hgrc configured
# with your username (otherwise you need to
# add your username at every commit)
mkdir /tmp/scm-tests
cd /tmp/scm-tests
# create a central repo
mkdir [scm]-central
git:
git init --bare git-central
# bare: you need to look at the man page to
# find this - needed otherwise you not be
# able to do push (you will need to go to central and pull)
hg:
hg init hg-central
# on the contrary hg assume by default
# that you can push (might be seen as
# a security issue - that doesn't bother me)
# user1 clone central
mkdir [scm]-user1
git:
git clone /tmp/scm-tests/git-central/ git-user1/
# you will get a 'warning: You appear to
# have cloned an empty repository.' I don't
# understand why they putted that ?! what's the problem here ?
hg:
hg clone /tmp/scm-tests/hg-central/ hg-user1/
# add and commit 2 initial files
$ cd [scm]-user1
$ ls
OTHER.TXT README.TXT
$ cat OTHER.TXT
other file
$ cat README.TXT
readme file
git:
git add README.TXT OTHER.TXT
git commit -a -m "user1 modif1"
# using the 'a' option or not
# could be a post on itself
hg:
hg add README.TXT OTHER.TXT
hg commit -m "user1 modif1"
# pushing modification to central repo
git:
git push origin master
# here you get some obscure
# message in the output like
# 'Delta compression using up to 2 threads'
hg:
hg push default
# creating user2 and cloning central
$ cd /tmp/scm-tests
mkdir [scm]-user2
git:
git clone /tmp/scm-tests/git-central/ git-user2/
hg:
hg clone /tmp/scm-tests/hg-central/ hg-user2/
# - - - - - - - - - - - - - - - - - - - -
# concurrent modification of different files
# - - - - - - - - - - - - - - - - - - - -
modify [scm]-user1/README.TXT
modify [scm]-user2/OTHER.TXT
git:
cd git-user1
git commit -a -m "user1 modif"
cd ../git-user2
git commit -a -m "user2 modif"
hg:
cd git-user1
hg commit -m "user1 modif"
cd ../git-user2
hg commit -m "user2 modif"
# push user2 modif to central
git:
git push origin
hg:
hg push default
# pull from user1
cd ../[scm]-user1
git:
git pull origin master
# I always have a doubt if it's
# origin master or the opposite
hg:
hg pull default
# notice that you don't need to tell
# hg where you want to send the changes
# it assume it's the current dir
...
(run 'hg heads' to see heads, 'hg merge' to merge)
# this message is important because it means you
# have to issue 2 extra command to merge otherwise you can't push
# the merge will be easy but in this case git just does it !
hg merge # we don't specify any revision,
# hg is smart enough to find the right one
hg commit -m "Merge" # by default in tortoisehg the
# commit message is already configured - don't know if it's
# a tortoisehg feature...
# push user1 modif to central
git:
git push origin
hg:
hg push default
# pull user1 modif in user2 folder
cd ../[scm]-user2
git:
git pull origin master
hg:
hg pull default
...
(run 'hg update' to get a working copy)
# again this message is important, hg fetched the central
# repo info, but didn't moved you automatically on the latest revision
# we could have done this by using the -update option,
# but I wanted to show you this situation
hg update # another extra command compare to git
# diplay graph of what we made
git:
git log --graph --color # notice the commit 'Merge branch...' was done
# automatically, we did nothing (except push and pull)
* commit 817f6e11a14530c6b09502edd069895ab19d8aea
|\ Merge: b0647d4 c0a4f25
| |
| | Merge branch 'master' of /tmp/scm-tests/git-central
| |
| * commit c0a4f259c33f8d8876088b08703776bb2739bb4a
| |
| | user2 modif
| |
* | commit b0647d415b30a407f0367ff96e5a417956d83d93
|/
|
| user1 modif
|
* commit 6ffe857f8ece5ea7df051975b36c4384bdbe1383
hg: # didn't found any text based graphical tool
# at first but apparently there is an
# extension off by default:
# http://mercurial.selenic.com/wiki/GraphlogExtension
hg log
hangeset: 3:2e322ec563c5
tag: tip
parent: 2:995f574cea3d
parent: 1:4d258b644a75
summary: Merge
changeset: 2:995f574cea3d
parent: 0:a3ebb2490ce5
summary: user1 modif
changeset: 1:4d258b644a75
summary: user2 modif
changeset: 0:a3ebb2490ce5
summary: user1 modif1
# git and hg: same number of revisions
# - - - - - - - - - - - - - - - - - - - -
# concurrent modification of the same file (with conflict)
# - - - - - - - - - - - - - - - - - - - -
modify [scm]-user1/README.TXT
modify [scm]-user2/README.TXT
the same line
commit code omitted
# push user1 to central
git:
git push origin
hg:
hg push default
# pull central to user2
cd ../[scm]-user2
git:
git pull origin master
...
Auto-merging README.TXT
CONFLICT (content): Merge conflict in README.TXT
Automatic merge failed; fix conflicts and then commit the result.
hg:
hg pull default
...
(run 'hg heads' to see heads, 'hg merge' to merge)
hg merge # extra command
merging README.TXT
warning: conflicts during merge.
merging README.TXT failed!
...
use 'hg resolve' to retry unresolved file merges or 'hg update -C' to abandon
# fix conflict by editing file
vi README.TXT
# mark file as merged
git:
git add README.TXT
git commit -a -m "fixing conflict"
hg:
hg resolve -m README.TXT # this m option was hard to find
hg commit -m "fixing conflict"
rm README.TXT.orig # I don't know if it's me not
# using hg properly or hg behavior but we need to
# cleanup manualy some backup file :(
# push user2 conflict fix to central
git:
git push origin
hg:
hg push default
# update user1
cd ../[scm]-user1
git:
git pull origin master
hg:
hg pull default
...
run 'hg update' to get a working copy)
hg update # extra command
# diplay graph of what we made
git:
git log --graph --color
# notice that this time there is no automatic merge message but ours
* commit 58e0ec598f272ac5d4dff02b7a9d0e3842a08c81
|\ Merge: 7c4b4dc e176f07
| |
| | fixing conflict
| |
| * commit e176f07da2db925528c7a068af5f558484af6f56
| |
| | user1 modif conflict
| |
* | commit 7c4b4dc8cbbb49138312df41fe19f2b2dee90d2b
|/
|
| user2 modif conflict
|
* commit 817f6e11a14530c6b09502edd069895ab19d8aea
...
hg:
hg log
changeset: 6:6f8dceccba2d
tag: tip
parent: 5:32085fee1b07
parent: 4:7417be83b483
summary: fixing conflict
changeset: 5:32085fee1b07
parent: 3:2e322ec563c5
summary: user2 modif2
changeset: 4:7417be83b483
summary: user1 modif2
changeset: 3:2e322ec563c5
...
# git and hg: same number of revision: 3
# - - - - - - - - - - - - - - - - - - - -
# conclusion
# - - - - - - - - - - - - - - - - - - - -
learning curve (if you already know svn):
git: not easy, need regular practice and at least
one week to become familiar with command line args
hg: 1 day, just feels like svn
commands:
git: 21 commands with (obscure) command line arguments
hg: 50 (obvious) commands
branches:
git: merging from branch is done with one command line
hg: you need to type extra (useless) command to merge in obvious (non conflicting changes) case.
Apparently the extra (useless) commands behavior can be change by tuning some conf parameter:
http://hgbook.red-bean.com/read/a-tour-of-mercurial-merging-work.html#sec:tour-merge:fetch
vocabulary:
git: origin
hg: default
windows support:
git: lame
hg: good (tortoisehg)
linux support:
git: good (git help are man pages)
hg: good enough
merge conflict:
git: easy
hg: less obvious / elegant
me:
I like both
hg: because it's so easy to use
git: for it's elegant way of handling merge and branches
