Re: [boost] [git] Mercurial?

Subject: Re: [boost] [git] Mercurial?
From: Jason Harris (jason_at_[hidden])
Date: 2012-03-22 00:01:34

> >>>>> Dave Abrahams <dave <at> boostpro.com> writes:
> 
> > More attention from the community, more support, more tools work with it,
> > more money behind it, more people will be familiar with it in the long run,
> > etc., etc.
> 
> Example: compare the number of commercial tools for working with Git, compared
> to those available for working with Mercurial.  On OS X along I can use:
> SourceTree, Tower, GitHub, GitBox, GitDiary, QuickHub, Octopus, and that's
> only the commercial tools!
> 
> By contrast, if I search for "mercurial" in the AppStore, I can only use
> SourceTree (which works with both).
> 

Well, I am the author of MacHg a very fully featured multithreaded osx client
for mercurial. There was murky and a few other clients around for OSX. But for
now the scene seems to have settled into MacHg and SourceTree. I would also
point out that I think the kiln team will soon have a nice port of TortiseHg to
OSX.

A partial listing of general tools is here: http://mercurial.selenic.com/wiki/OtherTools

(Note I have not put MacHg on the AppStore since it is a bit of a pain trying to
sand box the thing. I think Neil (the author of SourceTree) complained about the
fact that he could not include compiled python file etc, in the app store
version. Also a good GUI should have some command line drivers. Eg from the
command line you should be able to enter "machg somerepo" and have it open in
MacHg or something similar. (This has been on my to-do list for quite some
time.) And such tools contravene the AppStore guidelines. Eg BBedit had to
remove such tools from their application in order to get it onto the AppStore.
Eg see http://www.barebones.com/store/macappstore.html and the section about the
limitations of the AppStore version.))

I would think most developers would not be strictly limited to the AppStore
version and a simple google of "OSX mercurial" will turn up MacHg...

As to the whole discussion of Mercurial vs Git. I really have to say that both
products are quite similar now in what they can do. However, the learning curve
for me for git is just not good. Eg just for some simple comparisons do a:

[salt:~] ⌘ hg help pull | wc
      40     264    1753
[salt:~] ⌘ git help pull | wc
     638    3624   29834

These are basically the same commands. Yet, the size of the help entry for pull
for mercurial is 6% of the size of the git help entry. That says a lot about the
understandability of one system to the other. (cf the size difference for other
commands like pull, log, status, etc.)

Git has **soo** many bells and whistles. Every so often as a real DVCS ninja git
has something that mercurial doesn't have in my experience. Eg there is a
feature in git when you are doing a total conversion of a repository you can run
a filter over all of the files as you go. (eg imagine you want to convert all of
say windows newlines to unix newlines in every version stored in history, or
some other repetitive thing like this.) Up until a little while ago Mercurial
didn't have that feature. So on the extreme cases there are definitely bits to
git where git has more options.

However these extra command switches in git are definitely a very sharp double
edged sword in that for the average user the number of git options is just
insanely huge. Thus I think the mercurial philosophy of trying to keep things
clean, organized, and coherent is much better for at least 90% of users if not
more like 98% of users. I am sure that each of you and each of your colleagues
are gurus in a number of things, but do you want to require that they are gurus
in DVCS systems? Even in Mercurial a lot of the users I encounter are sometimes
woefully clued in to what is going on, and Mercurial is more streamlined, and
cleanly organized than git (in my humble personal experience.)

And it isn't all a bed of roses in Mercurial either. Eg there are things one
should really watch out for, for example in using sub-repositories (these
parallel sub-modules in git) one should use a thin super-repo layer. We got
bitten by this at our work and it has caused problems. See eg
http://mercurial.selenic.com/wiki/Subrepository#Recommendations

Other points to consider: Those people who think you can't edit history in
Mercurial or have many "branches" within a repo, their information is years
out of date... I edit history and rebase, etc all of the time. It is part of my
standard work flows.

The arguments about popularity might have some weight but I think Mercurial and
Git are definitely both large enough and will stick around. Besides converting
one repo to the other in case one disappears is not that difficult. There are
tools which interoperate between both formats (se hg-git.)

Also, being a GUI writer I would say the number of differences once you are
using a GUI is even smaller in day to day usage once you know what is going on.
One, difference is with git you have to be careful to name *everything* or you
get "detached heads". In mercurial you don't have to worry about this at all.
You can happily update to any revision and start working right there without
having to remember to name it / think up a name for it. (However, there are
certain advantages to naming everything since then you can track revisions
across all sorts of history edits, where-as in Mercurial you have to do some of
this tracking manually...)

(As a GUI writer I have thought about making the changes to MacHg to be able to
release MacGit, but ever time I start playing with git it just... I don't know...
I can go into details but the details would likely not be relevant here...)

In any case, I use boost in my projects and think it's fantastic! Whether you
all end up choosing git or hg a DVCS IMHO is much better than a centralized
VCS. (However, I haven't used svn extensively since the company I worked for has
skipped directly from cvs to mercurial & git.)

Also whether you choose hg or git you might want to have an official mirror in
the other system... So users can just use the system they want to.

Best of luck,
    Jason