Re: Deciding between Git/Mercurial

From: Jakub Narebski <jnareb@gmail.com>
Date: Sep 28, 2009, 23:11 UTC
Message-ID: <m33a66br69.fsf@localhost.localdomain>
In-Reply-To: <h9nlhj$heq$1@ger.gmane.org>

Anteru <newsgroups@catchall.shelter13.net> writes:

Show 10 quoted lines

> I'm currently evaluating DVCS for a project, and we're at a point where
> it comes down to either Mercurial or Git. Right now, I'm advocating for
> Git, while my co-workers like Mercurial, so I'd like to provide some
> good arguments in favor of git. Unfortunately, I'm not a git expert, so
> I hope I can get some help here ...
> 
> First of all, what's the matter with git and Windows, is there some
> long-term commitment to make git work on Windows as well as on Linux?
> I'm using msysgit on Windows, and personally I'm happy with it, but my
> co-workers constantly nag that Mercurial has superior portability ...

On one hand side Git relies quite a bit on POSIX features; also some of git commands are implemented as shell scripts, or are written in Perl. Nevertheless even if people stopped working on msysGit ("native" Windows port), which I don't see happening, there is always and will be git from Cygwin. But the msysGit team is active, and I predict that it soon would be full equivalent of Git on Linux (there are some corner cases yet). Lately there was even some work on support infrastructore for having Git be developed in MSVC.

On the other hand side Mercurial does have some parts of its code rewritten in C for efficiency. I do wonder how portable it is, and what is more important how portable is the interface between C and Python.

But I do not use MS Windows for development, and I do not use Mercurial...

Show 5 quoted lines

> Mercurial's revision number system: With git, I get an SHA1 hash for
> every commit, but it's not possible to see whether Hash1 is newer than
> Hash2, while Mecurial also adds a running number to each commit. What's
> the rationale behind this decision for git, and is it possible to
> emulate Mercurial's behavior somehow?

First, you have to remember that this 'number of commit' thingy is *local* to your repository, so you cannot use commit numbers to communicate with other developers. This is inherent and unavoidable property of 'revision numbering': commit identifiers must be derivable from commit contents (e.g. SHA-1 used by Git), or must be local to clone of repository (e.g. Mercurial), or there must be some central numbering authority (like in centralized SCMs like Subversion).

Second, I think advantages of revision numbering (running number) are overemphasized. I don't see how numbers such as 12678 and 12687 are easier to use than even abbreviated SHA-1 IDs like f06e7eb, never mind the "<branch>~<n>" syntax Git uses to refer to n-th ancestor of current tip of given branch. Besides with nonlinear history with revision numbers such as 12678 and 12687 you know that 12678 is older than 12687 if and only if 12678 and 12687 are on the same line of development.

Third, I think it would be possible to emulate mercurial behaviour with using lightweight 'number' tags for numbering, created from a hook.

Show 6 quoted lines

> Integration into tools: We're using Trac currently, which also has a
> nice binding to Mercurial (well, obviously easy to do as Mercurial is
> written in Python, just as Trac itself), while the git support is in
> development and looks quite alpha'ish. Do you plan to make it easier to
> integrate git with other tools by providing bindings to other languages,
> or is this a low-priority issue?

Well, I think that the problem with implementing bindings to other programming languages is that there is currently no such thing like the Git library (well, there are beginnings of one). This is caused by the fact that originally git commands were written in run-once philosophy, and e.g. rely on operating system to do the cleanups.

So far bindings to other languages either call Git commands (like Git.pm Perl interface from Git, or JavaGit), or are native Git (re)implementations relying not on stable API, but on stable repository format (JGit for Java, Dulwich for Python, partially Grit for Ruby).

The emphasisis in Git was (and is) for it to be *scriptable*, rather than extensible through plugins.

BTW. the fact that JGit is reimplementation allows it to be use different license than Git itself; license which makes JGit and EGit to be license-compatibile with Eclipse, and allow to distribute EGit as full Eclipse project.

Show 6 quoted lines

> 
> So far, my key arguments are that git is more robust (more projects
> using it, larger developer base), of course git's excellent performance
> and the much better support for SVN, which is important for us as we can
> slowly migrate from SVN->Git, while hgmercurial is still in the making
> (and Python's SVN->Hg switch is for instance waiting for it).

hgmercurial? or hgsubversion?

There is also fact that git has superior support for multi-branch development, which I think is the workflow most suited for distributed development.

-- 
Jakub Narebski
Poland
ShadeHawk on #git