Re: Deciding between Git/Mercurial

[Jakub Narebski <jnareb@gmail.com>]

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

> 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...

> 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.

> 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.

> 
> 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