Deciding between Git/Mercurial

Hi,

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

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?

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?

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

Cheers,
  Anteru

söndag 27 september 2009 14:24:32 skrev Anteru <newsgroups@catchall.shelter13.net>:

You have to read carefully. This (or the mercurial list) may not be the most objective sources of information.

Besides msysgit there is JGit and a port of it to C# (and thus any dotnet-ish language). The msysgit teams seems very committed and passionate about the project, but they need more assistance from genuine Windows users. Note that the current model of file locking can never work as well on Windows as it does on Unix. Something better is needed for flawless operation.

Might be somewhat true, but msysgit works very well. Not sure how mercurial handles unicode issues. CRLF issues seems to be ignored (not handled).

But those numbers cannot be communicated since they are local to your clone.

git-cvsserver has to do something along those line The numbering is per file.

Maintainers tend to tag versions using the common numbered schem and that is typically enough.

-- robin

Robin Rosenberg wrote:

Sure, but at the moment, I'm advocating pro-git, so I'm biased as well :)

Yeah, well, the main question here is actually: Is improved support for Windows one of the goals of future git development, or is this a complete non-issue?

Cheers,
  Anteru

On Sun, Sep 27, 2009 at 20:10, Anteru <newsgroups@catchall.shelter13.net> wrote:

I just hope it is not. Improved Windows support mostly means lots of dead code (and that's the best outcome), which no other platform can use.

Another thing to consider: For what kind of project/language do you need git? What build tools are you using and how good is the integration into both git and hg?

LieGrue, strub

--- On Sun, 9/27/09, Alex Riesen <raa.lkml@gmail.com> wrote:

Mark Struberg schrieb:

The project is running on Windows/Linux (Windows being the primary development platform, and we also expect most users to run Windows.)

For tooling, we use Trac at the moment (good integration with SVN), but we're evaluating GitTrac, Trac/Mercurial and Redmine now (+ possible migration paths.) For our build system, it's a non-issue anyway, as git/mercurial have command line clients, and that's all we need.

Don't get me wrong with Git+msysgit on Windows, the point is simply if we switch to git, can we expect that Windows will be supported for the foreseeable future or is it possible that git may simply drop Windows support completely? For Mercurial, this is a non-issue, as it is written in Python, and Python will support both Windows and Linux.

As I said, I'm happy with using msysgit, but I cannot find any roadmap etc. which helps me to determine how git and Windows is going to continue (for instance, I can find some complaints that git's performance is bad on Windows due to cygwin's fork()/exec(), is this likely to get ever "fixed"? I guess git# will solve this as soon as it's ready?)

Cheers,
  Anteru

On Sun, Sep 27, 2009 at 21:18, Anteru <newsgroups@catchall.shelter13.net> wrote:

Despite what I said, this is very unlikely (sadly). There are active developers whose professional life happens in Windows. Besides, the project is open- source and no one can stop you from taking over the maintainership of a port.

There isn't any. Roadmaps are for projects with a guaranteed end of life :-p

Not likely. OTOH, msysGIT does not have that part of performance problem.

On Sun, Sep 27, 2009 at 9:18 PM, Anteru <newsgroups@catchall.shelter13.net> wrote:

The chance of Windows support being dropped from git is very unlikely
- there's way too many people depending on git for Windows already for
that to happen. Besides, git is open source, so you can always fix
Windows issues yourself.

As for Mercurial, Python programs aren't automatically portable to Windows either. But I expect that they have the same very close to zero chance of having Windows support dropped as git has.

Git (neither mainline nor msysgit) doesn't have any official roadmap as far as I know. People just hack away on what they feel is important. If you want to make sure something gets done, chip in the development-time yourself.

As for the fork()-performance, this is only an issue for some tools (if any at all - I don't think this issue exists in msysgit). In my experience, git on Windows is faster than any other VCS I've ever used on Windows.

Le 27/09/2009 20:10, Anteru a écrit :

I think it is a non-issue as Git compile out of the box with Cygwin. Since many years I'm building Git almost daily from master under my Windows box using Cygwin. git-svn works like a charm too.

Pascal.

On Sun, Sep 27, 2009 at 8:01 PM, Robin Rosenberg <robin.rosenberg.lists@dewire.com> wrote:

You can use git-describe, which will look for the latest tag, and make a combo of latest tag, commits since the tag, short form of sha1. So you get "v1.6.3-33-g1234" - 33 commits after 1.6.3. Works very well to integrate in versioning. The git project itself uses it in the Makefile to set the versions, same as the kernel folk do -- I use it to version even RPM/DEBs.

hth,

m

On Sun, Sep 27, 2009 at 3:24 PM, Anteru <newsgroups@catchall.shelter13.net> wrote:

IMO the key difference between hg and git is the storage model: hg stores deltas, while git stores snapshots. That would mean that certain operations are theoretically faster in git (e.g. checkout, diff) while others faster in hg, although with git's packed format I guess there's no operation faster in hg. This means that it doesn't matter how much hg's python code improves, or if they even re-write parts in C, they will never be able to match git's performance (unless they change the storage model, which essentially means changing the whole design -- won't happen).

All this is just guesses, I've thought about doing some measurements but I haven't had time.

Cheers.

Felipe Contreras <felipe.contreras@gmail.com> writes:

Mercurial stores regular snapshots, to make sure you never have to apply too many deltas to get a snapshot. That's not so different from what Git does with its packed format (the difference is that Git's delta are not necessarily against the direct ancestor of the file).

AFAICT, both are snapshot-oriented, but both use a compression algorithm based on delta.

Hi,

I tried to refrain from commenting in this thread, because I do not want to encourage people just to use msysGit and never even attempt to fix their own issues.

But I cannot let this go uncommented:

On Mon, 28 Sep 2009, Felipe Contreras wrote:

That is wrong. "git log -- <file>" will always be slightly faster in Mercurial, for all the reasons you mentioned.

In addition, Mercurial _has_ parts re-written in C for performance, which renders it not-exactly more portable if you ask me. Last time I checked, there was no way to compile a Python module with MinGW (or for that matter, Python itself), but you needed MSVC...

Ciao, Dscho

On Mon, Sep 28, 2009 at 1:08 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Ok, thanks for pointing that out. I was thinking that maybe 'git blame' would also be slightly faster on hg, but I really don't know. Anyway, I think for most operations git would always be faster, and more importantly; some essential operations will be faster (checkout, diff <committish>).

Felipe Contreras <felipe.contreras@gmail.com> writes:

[...]

hg (and git) store binary deltas. AFAIK neither attempts to use those to produce output for blame, diff, etc. (git's deltas may well be slightly different from mercurial's, in that git's can be deltas with respect to something arbitrary so even if they had a suitable line-based format they'd be useless for diff, blame.)

Similarly for the other major systems, with the exception of (I think) bzr and darcs. (I don't know how bzr or darcs actually work, but IIRC they both have line-based storage that in principle might be usable in computing blame and diff.)

[...]

Johannes Schindelin schrieb:

I have a shortish mercurial build script that works under Cygwin 1.5 and uses msys, py2exe and iscc to build an installable Mercurial package, but I'm not sure what this boils down to WRT C-versions of "modules". Maybe these are lumped into the resulting hg.exe, I never bothered to check the details.

You better evaluate yourself on the project you are going to use git or Hg. Hg and git are used both by big companies. Google uses git to host android, where as it also uses Hg to host google wave! So don't go which company uses what, but try to evaluate... Check what is the kind of operations your developers do often? Is it checkout, diff, blame, also are they ready to do git gc often? What about developer who is not interested in using cli? How do u care them for operations they intended to do? what is the workflow? Which tools supports it to great extent?

At the end of day, it is a developer who spends much time using tool..

Just my opinion...... you put this question in Hg list, I bet you will get the different views....

The above is solely my opinion and I am not biased! I think so:)

On 9/27/09, Anteru <newsgroups@catchall.shelter13.net> wrote:

Hello,

* Anteru <newsgroups@catchall.shelter13.net> [2009-09-27 14:24]:

Trac is one of the the most well-known project management tools, but Indefero is also interesting, and itegrates Git better than Trac: http://www.indefero.net/

Best,

On Mon, Sep 28, 2009 at 1:54 PM, Damien Wyart <damien.wyart@gmail.com> wrote:

The interface looks very similar to Google Code's. I wonder, is this the same thing that Google is using, or is it just mimicking the interface?

- Steven

Heya,

On Mon, Sep 28, 2009 at 23:09, Steven Noonan <steven@uplinklabs.net> wrote:

Whow, it _does_ look a lot like Google Code, I doubt it's the same code as I don't think Google Code's verison is open source, pretty good copy either way.

Sverre> Whow, it _does_ look a lot like Google Code, I doubt it's the same Sverre> code as I don't think Google Code's verison is open source, pretty Sverre> good copy either way.

I gotta get these guys on FLOSS Weekly. Is anyone here a member of the team?

Heya,

On Tue, Sep 29, 2009 at 01:56, Randal L. Schwartz <merlyn@stonehenge.com> wrote:

There is of course the possiblity that the codesite team liked their design so much that they based theirs off of the Indefero thing :P.

2009/9/29 Randal L. Schwartz <merlyn@stonehenge.com>:

Not a member of the team, just a user (and bug reporter!), but I believe Indefero is almost all the work of one pretty amazing guy, Dr Loïc d'Anterroches, cc'd above.

Mike

Sverre Rabbelier <srabbelier@gmail.com> writes:

Indefero is a clone of Google code.

  http://www.google.com/search?q=indefero+clone+google+code

(most links are in French, but this is what they say)

Heya,

On Tue, Sep 29, 2009 at 10:21, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:

Might I suggest for those that are no masters of the french language:

http://translate.google.com/translate_s?hl=en&clss=&q=indefero+clone+google+code&sl=en&tl=fr

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

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

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.

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.

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 <jnareb@gmail.com> writes:

[...]

See also http://whygitisbetterthanx.com/#hg

Ah cool, thanks for clarifying this.

hgsubversion of course, which is supposed to be what git-svn is already. At the moment, I already use git with our SVN server, so I can show some of the advantages (for instance, renaming works much better than with SVN itself :) ), and I guess it also makes the migration easier as everyone can try with Git locally and we switch from SVN to Git once everyone has switched locally.

Thanks for all the input so far!

Cheers,
  Anteru

On 2009-09-28, Jakub Narebski <jnareb@gmail.com> wrote:

The statement above is incorrect!! In a Mercurial repo local revision numbers are strictly ordered in commit time. 12678 < 12687 means that 12678 was committed prior to 12687. But these two commits could belong to two completely unrelated lines of development.

--Leo--

On Tue, 29 Sep 2009, Leo Razoumov wrote:

This is impossible with distributed development. If the second branch comes from other repository, with commits _created_ (in that repository) earlier than commits in current repository, but commits in first branch (from current repository) were created earlier than _fetching_ those commits in second branch:

  .---.---.---.---x---1---2---3---M---.    
                   \             /
                    \-A---B---C-/             <-- from repository B

Either you would have to change commits numbers, and therefore they would be not stable, or you would have to change commit time to mean 'time this commit got into current repository', which would kill performance for sure.

Jakub Narebski <jnareb@gmail.com> writes:

Yes, the accurate statement is (I think): "In a Mercurial repo local revision numbers are strictly ordered according _the time when the_ _commit entered the repository_" (i.e. the time you did a merge, not the time the other guy did the commit).

Just tested:

$ hg log changeset: 3:4d6db21df0cd tag: tip parent: 1:31f8406ae59c parent: 2:33bfb84a5113 user: Matthieu Moy <Matthieu.Moy@imag.fr> date: Tue Sep 29 21:54:25 2009 +0200 summary: merge

changeset: 2:33bfb84a5113 parent: 0:a508b050e5ae user: Matthieu Moy <Matthieu.Moy@imag.fr> date: Tue Sep 29 21:54:02 2009 +0200 summary: in branch bar

changeset: 1:31f8406ae59c user: Matthieu Moy <Matthieu.Moy@imag.fr> date: Tue Sep 29 21:54:11 2009 +0200 summary: in branch foo

changeset: 0:a508b050e5ae user: Matthieu Moy <Matthieu.Moy@imag.fr> date: Tue Sep 29 21:53:33 2009 +0200 summary: init

Either I have a time machine at home, or changesets 1 was not made before changeset 2.

On 2009-09-29, Jakub Narebski <jnareb@gmail.com> wrote:

Jakub, in Mercurial sequential commit numbers are local to a repo and are not unique between the clones. Unique ID is SHA1 as in git. So mercurial commit 127:aaf123453dfgdfgddd... means commit number 127 in this repo with SHA1 "aaf123453dfgdfgddd..." In another clone commit 127 might mean completely different thing. Sequential commit numbers are strictly for "local convenience".

--Leo--

On 2009.09.29 20:49:52 -0400, Leo Razoumov wrote:

To quote his first mail:
	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.

With the above example, he has just shown that even with those local commit numbers, you can't tell that commit X is older than commit Y just because X < Y.

Björn

On 09/30/2009 02:49 AM, Leo Razoumov wrote:

Personally I much prefer the "commit'ish-backward" notation of git, where HEAD~4 means "the commit 4 commits back from HEAD".

You'd get awfully tired of writing the six-digit "shorthand" numbers of large projects fairly quickly, I imagine.

On Wed, 30 Sep 2009, Leo Razoumov wrote:

Yes, I know that in Mercurial commit numbers are local to repository, and even written about it (that sequential commit numbers are possible only either as local identifiers, or in centralized workflow).

The issue I was writing about that sequential commit numbers cannot tell us if commit was earlier or later than some other commit based solely on those commit numbers. As other people in this thread wrote Mercurial numbers commits not in order of commit creation, but in order of commit arriving (being present) in given repository. So commit numbers are not 'strictly ordered in commit time', but ordered in 'time commit got into current (local) repository'.

I'd like also to note that this means that at some time Mercurial has to number all those commit it got on fetch / pull from remote repository. This can be a lot of work... work which Git doesn't have to do (OTOH Git creates index for packfile on local side after fetch...).

On 09/27/2009 02:24 PM, Anteru wrote:

While not exactly the same thing, 'git describe' is very helpful in comparing versions (if you know that one is an ancestor of the other).

Paolo

On Sun, Sep 27, 2009 at 2:24 PM, Anteru <newsgroups@catchall.shelter13.net> wrote:

Can I propose to make this discussion cross-mailing list adding the hg mailing list to the CC? I think it would be a good discussion if we don't end up flaming. Let me know what you think about it

about the Windows+Git compatibility, you may consider TortoiseGit too for the not-CLI-oriented guys; I've seen it a while ago and it seems pettry well integrated with windows

If you tag a commit then you should be able to see how many commits there are from that one issuing a git describe (found on the internet) git commit -m'Commit One.' git tag -a -m'Tag One.' 1.2.3 git describe # => 1.2.3 git commit -m'Commit Two.' git describe # => 1.2.3-1-gaac161d git commit -m'Commit Three.' git describe # => 1.2.3-2-g462715d git tag -a -m'Tag Two.' 2.0.0 git describe # => 2.0.0

On Tue, Sep 29, 2009 at 2:14 PM, Daniele Segato <daniele.bilug@gmail.com> wrote:

We will probably end in flames. Its same as comparing Vim and Emacs, Python and Perl...

...this comparison is all ver web. Checkout!

http://importantshock.wordpress.com/2008/08/07/git-vs-mercurial/

My *personnel* opinion is, If it is for project _only_ on UNIX, than GIT and repo tool from Google will be killing combination.

If project is on both Windows & UNIX (But consider where do you compile your code), than hg doesn't have matching!

Anteru schrieb:

That tale is told all over, but that doesn't make it truer. I've never had issues getting a Cygwin version of git to work properly (haven't tried the msysgit or jgit variants, never felt the need), and integration went smooth.

With Mercurial, getting it integrated with a Windows-native Emacs (Cygwin emacs doesn't work for me but hangs on startup) was somewhat of an undertaking even with Cygwin's bash (rather than cmdproxy) underneath Emacs. It boiled down to building Mercurial with py2exe and create an installer and use the compiled hg.exe which I find starts rather slowly.

Yes, but beware of git-svn under Cygwin 1.5 - that works for svn+ssh:// URLs, but https:// or file:// don't work well because the underdocumented gazillion of dependencies piece of sh.. called apr does stupid things WRT temporary files since the Cygwin Subversion 1.6 days. Cygwin's Subversion 1.5 fared better.

I'm not sure about msysgit or jgit projects, but for Cygwin you'll definitely want to take the plunge and go for Cygwin 1.7 which is still in Beta (because that allows you to remove a file and create a file with the same name, which doesn't work with Cygwin 1.5).

On Wed, 30 Sep 2009, Matthias Andree wrote:

Git works fine under Windows for people who use Cygwin. Portability to Windows is more about working for users who don't use a shell of any sort or the "Run..." dialog. I don't know how Mercurial does on that metric, anyway, but it's a lot more meaningful that the question of whether the software works in your POSIX environment when the underlying kernel is not very suitable.

	-Daniel
*This .sig left intentionally blank*

Hi Anteru,

On Sun, Sep 27, 2009 at 5:54 PM, Anteru  wrote:

..snip..

So finally which you choosed? Just curious?

Dilip M schrieb:

Bzr, it has even better SVN interop, works the same across all platforms, performance-wise, Bzr 2.x turned out to be more than sufficient and the UI tools are quite polished.

Thanks for all the comments on Git and Hg!

Cheers,
  Anteru

On Thu, Oct 22, 2009 at 12:20 PM, Anteru <Anteru@shelter13.net> wrote:

Surprised to know. I was expecting hg or GIT :)

Do you mind to share the checks done / piloting done while choosing Bzr over GIT or HG

I bet, it is useful for many ppl in this list too.

Dilip M schrieb:

Yeah, me too, actually, Bzr was no contender at first.

I'm going to blog about this, in the hope that it will help more people who want to switch away from SVN. I'm not so sure whether sending it here will help, because in order to be fair, I would have to send the same to the Bzr and Hg mailing lists, and this is a sure recipe for a flame-war :)

Cheers,
  Anteru