Git vs. Mercurial

Personally I'm more a fan of Git with the main reason being: Branching.

As far as I know Git still has problems handling Windows which is something Mercurial has never had to worry about. But since i am not a windows user (lover, or any other positive opinion holder), i don't really care.


Git

Pros
Lots of features
More hosting options.
Faster - slightly.
GitHub.
Solid local branch support.

Cons
Poor Windows support
Rubbish logo
Silly, long SHA1 hash of revisions.
You need to keep 'packing' the repo
History fiddling.


Mercurial

Pros
Portable
Its built with Python
Easily extensible using Python
Cool logo
Better documentation.
Local integer revision numbers on top of the SHA1
No need to keep packing/optimising.
Smaller repo footprint.
Better patch support (bundles and such)
Easy to learn.

Cons
Smaller feature set.
Few 3rd party hosting options.
Fewer 3rd party apps and plugins.
Smaller community.
Slower development.


Who Uses What

Mercurial
Mozilla
OpenSolaris
Aptitude
Netbeans
Dovecot

Git
Ruby on Rails Core
Linux Kernel
Google Android
Beryl
Fedora


Who Needs What
Mercurial is great for people who want to dive into distributed version control and get busy. Its clean, fast and easy to learn.

Git is for those who wish to fully exercise the benefits of source control and avoid the down's often happen when collaborating code.

A little bit abot Git

Distributed Nature

Git was designed from the ground up as a distributed version control system.

In a distributed version control software like Git every user has a complete copy of the repository data stored locally (a.k.a a local working copy), thereby making access to file history extremely fast, as well as allowing full functionality and access when disconnected from the network. It also means every user has a complete backup of the repository. If any repository is lost due to system failure only the changes which were unique to that repository are lost. If users frequently push and fetch changes with each other this tends to be an incredibly small amount of loss, if any at all.

In a centralized VCS like Subversion only the central repository has the complete history. This means that users must communicate over the network with the central repository to obtain older versions for a file, Backups must be maintained independently and if the central repository is lost due to system failure it must be restored from backup and all changes since that last backup are likely to be lost. (Depending on the backup policies).

Access Control

Due to being distributed, you inherently do not have to give commit access to other people. Instead, you decide when to merge what from whom.

Branch Handling

Branches in Git are a core concept used everyday by every user. In Subversion they are almost an afterthought and tend to be avoided unless absolutely necessary.

The reason branches are so core in Git is every developer's working directory is itself a branch. Even if two developers are modifying two different unrelated files at the same time it's easy to view these two different working directories as different branches stemming from the same common base revision of the project.

So than Git:

• Automatically tracks the project revision the branch started from.
  • Knowing the starting point of a branch is necessary in order to successfully merge the branch back to the main trunk that it came from.
• Automatically records branch merge events.
  • Merge records always include the following details:
  • Who performed the merge.
  • What branch(es) and revision(s) were merged.
    • All changes made on the branch(es) remain attributed to the original authors and the original timestamps of those changes.
  • What additional changes were made to complete the merge successfully.
    • Any changes made during the merge that is beyond those made on the branch(es) being merged is attributed to the user performing the merge.
  • When the merge was done

  • Why the merge was done (optional; can be supplied by the user).

• Automatically starts the next merge at the last merge.
  • Knowing what revision was last merged is necessary in order to successfully merge the same branches together again in the future.

Performance

Git is extremely fast. Since all operations (except for push and fetch) are local there is no network latency involved to:

• Perform a diff.
• View file history.
• Commit changes.
• Merge branches.
• Obtain any other revision of a file (not just the prior committed revision).
• Switch branches.

Space Requirements

Git's repository and working directory sizes are extremely small when compared to SVN.

Simple install Git on Leopard


mkdir -p ~/Downloads/src
cd ~/Downloads/src

# Set options since we don't have GNU gettext installed
export TCL_PATH=`which tclsh`
export NO_MSGFMT=1
export GIT_VERSION='1.6.0.2'

# Get and install git
curl -O "http://kernel.org/pub/software/scm/git/git-$GIT_VERSION.tar.bz2"
tar xjvf "git-$GIT_VERSION.tar.bz2"
cd "git-$GIT_VERSION/"

# When on Mac OS X
./configure
make
sudo make install

cd ..

# Install Man Pages
curl -O "http://kernel.org/pub/software/scm/git/git-manpages-$GIT_VERSION.tar.bz2"
sudo tar xjv -C /usr/local/share/man -f "git-manpages-$GIT_VERSION.tar.bz2"



Stepping Up: Migrating from an SVN to a Git repository

pull the svn history into a new git repository:

* mkdir project_name.svn
* cd project_name.svn
* git svn init path/to/svn/repo —no-metadata
* echo “svn_username = Real Name ” > users.txt
* git config svn.authorsfile users.txt
* git svn fetch

make an svn-free git repository:

* mkdir project_name.git
* cd project_name.git
* git init
* git remote add origin path/to/git/repo
* git pull project_name.svn
* git push origin master

yippie!