
Mercurial developer responds to "Switch to git?" - St-Clock
https://groups.google.com/forum/#!msg/codereview-discuss/ilUffSph68I/NCldEt2Ii-4J
======
ggchappell
Articles like this worry me a lot.

Most of this post leaves me thinking, "Why should I be worrying about things
like this?" A fair amount of it leaves me at least somewhat boggled; I suspect
I'm not alone here. The idea that a user of a DVCS needs to be familiar with
issues like these tells me that something is seriously wrong with the design
of DVCSs.

Remember, a DVCS is a tool we use to track and store data related to a
project. The _project_ is what we are interested in: the Python or C++ or
LaTeX or whatever. Git, Mercurial, etc. are just there to help us keep track
of the real work. Time spent dealing with the intricacies of Git is time not
spent on the primary task -- the thing that Git is supposed to _help_ us with.

Consider filesystems, which are also tools used to manage stored data. If I'm
writing some Python thing, I don't proclaim to everyone that I'm storing my
work on a ReiserFS volume, and I'm thrilled by the fact that ReiserFS indexes
its metadata using a B+ Tree. I just store my data.

I think a well-designed DVCS would be thought of in much the same way.
Clearly, current DVCSs aren't. Something is very much amiss, folks.

~~~
ams6110
Articles like this make me wonder if I'm stupid. 95% of the time all I ever do
is commit my work and push/pull, whether I'm using svn, git, or hg. I just
hardly ever find myself needing to understand anything more complicated than
that. Why does it seem like everyone else has spent thousands of hours
understanding esoteric git or hg incantations that I've never encountered the
need for.

~~~
gbog
Maybe you could let git influence and hopefully improve the way you work.

For instance, when refactoring something quite complex with good test
coverage, you want each commit to be the smallest atomic commit that can pass
all tests. But you also want to very quickly and "carelessly" add debug logs,
assertions, changes in many files. For this kind of task I have found the
following workflow to be very helpful and fast:

1\. edit files relentlessly running a few tests cases

2\. when you feel you "got" something run full test suite

3\. if 2. pass, use `git add -p` to add the smallest changeset doing the
thing.

4\. Use `git stash --keep-index` to remove all other changes

5\. Run full test suite

6\. If 5. fails `git add -p` to continue editing your commit, or `git reset`
if too far off

7\. If 5. pass, `git commit` and `git reset --hard`.

Edit: When using `git add -p` you can even use 'e' command to manually edit
your patch.

~~~
naitbit
I'm sure that git with it's very powerfull backend has way for improving way
someone works, but I'm not convinced by this example. IMO it shows again that
usability of git is far from perfect. For example in bzr to accomplish this
task you can:

1\. (same)

2\. (same)

3\. put all changes that you are not interested in on shelve: `bzr shelve` (or
qshelve if you want QT gui)

4\. Run full test suite

5\. If 4. fails keep editing

6\. If 4. pass `bzr commit` (or `bzr ci`), and to revert shelving use `bzr
unshelve`

You need to remember 6+ git command to accomplish this tasks, and only 3 with
bzr. Moreover there is symmetry in bzr (fe: shelve - unshelve, commit -
uncommit) that is no present in git.

edit: formatting

~~~
gbog
> 3\. put all changes that you are not interested in on shelve

Usually what I want is the opposite: cherry pick a few changes, increasingly
adding them to the staging area (or index in gitspeak), because oftentimes I
have a change that I am not sure is required for this patch.

I was very unconvinced by the staging area thing when starting using git and
tried to avoid it, but in fact it is very powerful and not that complex. I do
not know bzr and only used hg for a few months so maybe they have similar
tools, but my main point is not git against the other, it is learn power uses
of the tools to help improve workflow, against the claim that dcvs should be
not our concern.

------
jheriko
i am worried about the popularity of git to be honest. i'm convinced it is
popular rather than good.

"I've really tried to 'get into' mercurial's mindset several times now, but
never could, whereas, IMO, git's model is simple and powerful. "

I find it hard to understand what this means, but this is typical of the
arguments i see for using git. really the core concepts of DVCS are the same
no matter what tool you use, and actually i consider the things that git does
differently to hg to be demonstrably and measurably counter-intuitive and in
some cases dangerous.

the biggest problem by far is that _git is dangerous out of the box_ \- it can
destroy your work very easily or leave you in an unrecoverable state.

why can't i roll back a merge in one step if i didn't configure things to be
able to do that? why does my branch disappear when i merge? how do the jenkins
guys break their repo so casually and find themselves struggling to recover
it?

i believe this is the robustness mentioned here: "The changeset graph is in
some sense more "robust" in that it's just there and doesn't change on its own
initiative"

mercurial seems loathe to alter history - which is pretty sane and common
sensical seeming to me, git does it as part of how it is 'supposed to be used'
which frankly sounds as mad as travelling back in time to shoot your
grandfather. for these reasons - to me - using git is asking for trouble (it
has caused me trouble and i switched to hg for precisely this reason).

i cant reasonably recommend git to anyone... which is a shame. other than that
flaw it is really quite rich and powerful and has other advantages over
mercurial - including (perhaps foremost) its enormous popularity.

EDIT: watch as this gets downvoted from hipster gut responses instead of
thought :D

~~~
jxf
> (...) _the biggest problem by far is that git is dangerous out of the box -
> it can destroy your work very easily or leave you in an unrecoverable
> state._

It's almost impossible to leave git in "an unrecoverable state", short of
actually deleting your ".git" directory.

If you do wind up in a bad spot, that's what the ref-log is for [0]. If you've
made an error that is difficult or complicated to unwind, no sweat: hit the
reflog and go back in time to the point where things were the way you wanted.

git is many things -- frequently useful, often complicated, sometimes obtuse.
But it's almost always safe.

[0]: [https://www.kernel.org/pub/software/scm/git/docs/git-
reflog....](https://www.kernel.org/pub/software/scm/git/docs/git-reflog.html)

~~~
steveklabnik
> git reflog

This, a thousand times this. Unless you happen to randomly run `git gc` for
some odd reason, you have a few months (with default settings) until your repo
is in an unrecoverable state, unless you touch the .git directory directly.

~~~
JoshTriplett
Even if you _do_ run git gc, by default git will still keep the reflog and all
objects reachable from it around for 30 days.

------
tracker1
I really appreciated that this response was not overbearing, or just raw
opinion, and rather compared many of the similarities and differences from
mercurial to git, and how they approach similar issues differently.

Honestly, I've struggled in moving from SVN/TFS to GIT, but it's been
worthwhile.. having local branching, and being able to work locally is great.
I can't really compare this to hg, as I haven't worked with mercurial at all.

The company I work for has moved a lot of its' development to a github
enterprise deployment, and it's been interesting. I like git extensions for
windows, though it's a bit rough around the edges. It's also a bit limited in
terms of VS integration, but I can manage. I think that Tortoise + Ankh was a
better combination overall in terms of the polish of the tooling, over what
git currently offers.

I tend to now work with a few console windows open, and have been using the
command line much more.

~~~
_stephan
You should try SourceTree, it's a great Windows and Mac Git GUI client! It's
free (as in beer) and also supports Mercurial.

~~~
voltagex_
I second SourceTree - if there's something missing that you need, Atlassian
are surprisingly responsive to feature and bug reports.

~~~
yapcguy
I like SourceTree but it the UI gets clunky and slow within a short period of
time. Not sure why, but it usually happens when you have anything more than a
trivial number of commits.

~~~
_stephan
Have you tried it in the last few days? After SourceTree got relatively slow
for me with the past few updates, the last update actually completely fixed
that!

~~~
emn13
I use SourceTree for git, but I find TortoiseHg is better for mercurial; it's
just far more feature complete, with support for almost all mercurial commands
and (bundled) extensions.

I'm still somewhat surprised by how poor git gui's are, considering it's the
more popular VCS - though SourceTree is certainly one of the better ones.

~~~
luastoned
I was really happy when I heard about SourceTree(back then it was not even
released yet) but when it finally came out it was bulky to begin with.

TortoiseHg on the other hand always looked nice and clean.

------
tytso
After reading most of the comments, and having participated on more than a few
git vs. <insert random DCVS> discussions, here are what I hope are some
hopefully new contributions.

All systems have different tradeoffs depending the target audience that they
are trying to optimize for. When comparing bzr, hg, and git, one way of
thinking about it is that they differ in the size of the developer community
of the project that they are trying to optimize for. The sweet spot of bzr is
probably up to ten or so active developers at one time; for hg, it's probably
up to around hundred or so; and for git, it's designed to scale up to several
thousand active developers. Different people might want to argue over the
exact breakpoints, but in terms of orders of magnitude, I think it's pretty
close.

One comment that was made in a thread below was that git was optimized for the
people who integrate code, as opposed for those who actually produce the code
--- and I think that's mostly true. Which is to say, when there was a choice
between optimizing for a project which might make things easier for the
integrator, or for the sub-integrator, or sub-sub-integrators (in Linux code
integration happens in hierarchically; it's the only way we can scale), and
making it easier for a newbie coder, git has very unapologetically optimized
for the former. It's true that there are some warts which caused by legacy UI
decisions which would probably have made differently if the designers could go
back in time, but in my mind these are in the cateogry of things like TAB
characters being significant in Makefiles; it's annoying, but practitioners
very quickly learn how to deal with these warts, and they generally don't
cause significant problems once people get over the startup hump.

The other observation is that since choice of which DCVS gets made is
generally made by project leads, who tend to be the integrators, it's not that
surprising that git is very popular for them. It's also true that most project
leads tend to be over-optimistic about whether their project will be the one
that will grow up to have thousands of active committers (just as most startup
founders are convinced that their baby will be the defeat the odds and become
the wildly successful IPO whose market cap will exceed $4 billion dollars :-).

Given that most projects generally don't have thousands and thousands of
active developers, it might be that hg is a better choice for most projects.
However, if most of your senior developers are more used to using git, because
that's what they are mostly familiar with, maybe you might want to use git
even though the project's scale is one that would be quite satisfied with hg.
For me, the e2fsprogs project falls in that category; while the number active
developers are such that hg would be fine, most of the developers are simply
much more used to git, and so we use git.

The third reason why git has probably become popular is because github is
really good at hiding many of git's rough edges, and if people are used to
github, then it might be a good set of training wheels before people graduate
to using git without github's training wheels.

If these three factors don't apply to your community, then maybe hg is a
better choice for you. If that's true, then don't hesitate! One thing that
most people forget is that while transitioning between DCVS is painful, it can
be done. So if it turns out the situation changes in three or five years, it
is certainly possible to convert your project from hg to git. It will be rough
for a month or two, but for some projects, that might actually be better than
starting with git, and then finding out that it caused some increased friction
initially, and that they never needed the scale that git provides.

------
St-Clock
I quit using Mercurial around 1.4 and was happily surprised by all the
improvements in 2.8 (shelve, bookmark improvements, etc.). Martin Geisler's
reply was both thoughtful and respectful, a rare sight in this debate.

~~~
weaksauce
> Martin Geisler's reply was both thoughtful and respectful, a rare sight in
> this debate.

I have seen this debate plenty of times but I'd hesitate to say that the
overwhelming majority of times are hostile.

I think the mercurial guys know that their tool is good with some flaws and
that they know that the git tool is good with some flaws and that most other
tools are not quite as good. The typical reaction that I have seen is I don't
care which one you use if you are using git or hg or some other equally
capable revision control scheme.

I definitely agree that Mr. Geilser's response was well thought out and
polite.

------
DigitalSea
It's refreshing to see someone with a level-headed response who doesn't fly
off the rails defending their source control tool of choice, unlike what you
usually see with developers of well-known frameworks like PHP and Ruby. I
don't personally use Mercurial myself, but it doesn't seem like a bad source
control choice, anything is better than SVN, right? Git and Mercurial both
seem like great and sensible choices.

~~~
nostrademons
This type of response is quite common in many open-source communities.

The trick to finding it is to consider carefully the motivations of _why_
someone wants to participate in open-source. If you have a problem, you wrote
a tool to solve it, and you want to share that tool with the rest of the
world, you won't be threatened when someone else has a competing tool to share
with the rest of the world. Just explain _why_ your tool is useful, and under
what circumstances, and let people make up their own minds. It's no skin off
your back if they choose not to use it.

If you participate in open-source to gain social approval and hacker cred,
however, then it's very threatening when other people choose to use a
competing tool. If your users disappear, so will your social approval, and
you'll be left feeling alone and unwanted. And so people who are in open-
source for this motivation frequently put-down technologies that that compete
with their own favorite tools. Sometimes it's not even the tools' authors that
do this; it is people who have adopted the tool and feel like their choice of
preferred tool will be threatened if others adopt different tools. Hence,
fanboyism.

I have found, when evaluating technologies, that I rarely go wrong trying to
select for the first category of community over the second. The problem is
that there's a bit of an adverse selection effect. If you ask "What's the best
framework for X?", then all the people in the second category will rush to
defend their favorite tool, while the people in the first category may present
cogent arguments for their tool of choice but won't seem all that impassioned.
Human beings are hard-wired to recognize passion, but we typically cannot
recognize experience until we have had that experience itself. And so your
natural tendency will be to pick frameworks in the second category unless you
specifically try to look past the arguments and look at the motivations and
background of the people making the arguments.

------
philliphaydon
I don't think Mercurial is the issue here...

Google Code is the issue... Didn't realise people still used that, its worse
than Codeplex. Atleast use Bitbucket or something that makes it easier for
people to contribute to while still keeping it with Mercurial.

I've found bugs in stuff before and ended up using a different project/library
for the sole reason that I found out its in Google Code and the amount of
effort involved in using the site let alone raising an issue or fixing it just
wasn't worth it.

~~~
leokun
Agreed, Google Code is awful. The tree ui for browsing code is so very
terrible. Browsing commits is a terrible pain. Viewing diffs is awful. And the
site just looks ugly and is hard to use. I was tired of Google Code before I
even knew about GitHub, I had switched to Unfuddle.

------
shadowmint
I think the big summary of this post comes down to, if you don't have
something like:

    
    
        [extensions]
        shelve =
        histedit =
        rebase =
        mq =
    

As a git developer using hg you're going to be frustrated by all the things
'hg doesn't support'.

It doesn't actually not support them, they're just (for some reason?) shipped
with hg but not turned on by default.

~~~
asperous
I'm not sure about shelve, but histedit, rebase, and mq are all history
modifying extensions. Mercurial differs from git in that it prefers immutable
history.

The extensions are there if you really need them, not as something you should
always setup imo.

~~~
mrtngslr
I don't think this is true today. Git and Mercurial have the same basic model,
which means that a commit is immutable because the identity of a commit is
determined by its content.

This means that you must re-create a changeset in both systems if you want to
"change" it. Mercurial and Git can do this and have been doing it for years.
The difference is that Git has a built-in concept of garbage collection
whereas Mercurial does not. So commands that modify history in Mercurial must
trigger the garbage collection (we call it strip) manually -- and they do, of
course.

So you wont see any big difference between 'hg rebase' and 'git rebase'. They
both build new commits and remove the old commits (in Git they're removed
eventually, in Mercurial they're removed immediatedly, but with a backup if
you want to restore the pre-rebase state).

The latest versions of Mercurial has history modification built-in: you can
'hg commit --amend' without enabling any extensions. The changeset evolution
concept will take this even further and allow really cool collaborative
editing of _shared_ history.

------
fhd2
After 4 years of Git and 1 year of Mercurial, I like them roughly equally. I
love cheap local branches, I also love MQ. They're just tools, I wish people
could get over this kind of stuff.

If this is really about getting more contributors, I suggest a GitHub mirror.
We do that, it's not a big deal (hg-git is pretty good), and it does get us
more contributors.

------
encoderer
Having used both extensively, Git at one job, HG at the next, now Git again, I
mostly have this to say:

Both tools lack polish.

The biggest piece of mis-information I'd like to clear up is that often times
a user new to either of these makes a few mistakes and then the cold hand of
death grabs them and they're certain they lost work. You never really do. In
Mercurial, the permanent nature of named branches and in Git the reflog both
serve you well. Seek help in such a case, because if you think you lost work,
you almost certainly didn't.

Edit:

Also, if you're using HG and not using patch queues, you're doing it wrong.
Just sayin'

~~~
eru
I've used patch queues with hg, but there are other tools available. For
example bookmarks allow you to use hg more like git.

Hg with patch queues is a bit like using git and always rebasing, almost never
merging. You do lose history with patch queues.

------
riannucci
Author/thread starter here: Really didn't think this post would have generated
as much interest as it did when I created it... :D

It's a fairly enlightening thread though. Mad props to Martin for a
fantastically thoughtful reply!

~~~
CmonDev
So, you are not switching now, hopefully?

------
eddiegroves
Mercurial's changeset evolution sounds really powerful and seems to address
the 'git rebase and force push' problems that can occur.

~~~
cpeterso
Here's a video of a FOSDEM 2013 talk about Mercurial's changeset evolution:

[https://air.mozilla.org/changesets-evolution-with-
mercurial/](https://air.mozilla.org/changesets-evolution-with-mercurial/)

------
cbhl
Part of me wonders whether this is an instance of "The Magpie Developer"[0]. I
know that I personally prefer git and bzr over cvs and svn, but just ten years
ago, people were all talking about how Linux had just switched to BitKeeper.

I also suspect that rather than having a bikeshed-esque argument about
switching between one DVCS and another, we can come up with technical
solutions to enable everyone to work together. For example, when I was
interning at Facebook two years ago, git-svn was used extensively to let the
rank-and-file employees work with git, while still allowing chuckr to deploy
off of SVN.

For mercurial and git, there are services like Kiln Harmony[1] and hg-git,
too.

[0] [http://www.codinghorror.com/blog/2008/01/the-magpie-
develope...](http://www.codinghorror.com/blog/2008/01/the-magpie-
developer.html)

[1] [https://secure.fogcreek.com/kiln/](https://secure.fogcreek.com/kiln/)

------
oleganza
"The local revision numbers play no role here -- btw, they're just an
(arbitrary) ordering of the commits in your local repository. No magic there."

I disagree. Mercurial is famous for its "simple" revision numbers that differ
between repositories. These revision number _are_ magical as they can suddenly
change when you merge some branches and older commits get pulled into your
history. Since mercurial and git are mostly about collaboration, non-stable
identifiers can be very confusing.

~~~
gecko
They can't change in a given repo unless you use history-modifying extensions.
They do differ between repos. Most modern third-party tools, including Kiln,
hide them by default for this reason.

~~~
oleganza
Thanks for clarifying this. I haven't touched mercurial for a while.

------
MikeTLive
Ive been using perforce/p4 since 97. the last 8 years have been coupled with
P4V and the eclipse plugins. My workflow is virtually identical to the much
offered Git branching model [0]. Turn it -90deg with time left to right.
Rename "develop" to "trunk". and think of "master" as being the release
labels. release and feature branches are created from the build label of the
previous release needing special changes that can not just go into trunk or
when we want to do a minimal patch-only release. a developer makes local copy
of the portions of the trunk they want/need. the server knows who has what
opened for edit/add which makes checkins fast. only the change must go in.
same for regular update of my local workspace. we rarely have people editing
the same exact file and if we do its a simple resolve in P4V during your
commit or integrate activity.

So far, there are FEW benefits i see to using, or switching to, GIT: LOCAL
REPOSITORY - I have the whole repo for what i am working on so can work remote
easier LOCAL VERSIONING - I can create lightweight local branches that
duplicate only what is required without resync of my local repo POPULARITY -
all the cook kids are using it so lots of ops utilities now are built
expecting it to be there under the covers.

I can live without the LOCAL benefits. I have for 8 years. I worry about the
third - popularity vs. merit.

Where are the concrete comparisons showing all the features and functions of
these solutions side by side and how they compare for a student, startup, or
enterprise?

EDIT: found a newer perforce:git comparison on the perforce site[1]. The LOCAL
REPO/VERSIONING is available with P4SANDBOXING.

I suppose modding me down is appropriate since i picked up on the POPULARITY
aspect of the discussion and don't have any Hg experience. However, it seems
these discussions just keep happening and there is no one-true-solution or
approach. they each have merits and faults. it will be the careful
consideration of these that leads to your own solution implementation. The
popularity of GIT appears to be its strongest argument.

EDIT2: located a GIT-v-Perforce on SO.[2]

so many of the diffs, however, have been met with sandboxing

It really appears the strength is in popularity - everyone else uses GIT so
you should too…

[0]: [http://nvie.com/posts/a-successful-git-branching-
model/](http://nvie.com/posts/a-successful-git-branching-model/) [1]:
[http://www.perforce.com/sites/default/files/pdf/perforce-
git...](http://www.perforce.com/sites/default/files/pdf/perforce-git-
comparison.pdf) [2]: [http://stackoverflow.com/questions/222782/git-vs-
perforce-tw...](http://stackoverflow.com/questions/222782/git-vs-perforce-two-
vcs-will-enter-one-will-leave)

~~~
rallison
I'll mention that a number of the answers covered in this StackOverflow post
[1] (note, that post is old, so it is entirely possible that perforce has
improved since then) cover a number of the reasons I prefer git over perforce,
but, for me, cheap branching and speed (due to everything being local) are
probably the two biggest.

Cheap branching, especially, completely changed my workflow. When a branch is
effectively free, and switching between branches is quick, a lot of doors are
opened.

And I say this as someone who really liked perforce previously. I just think
git is more capable, albeit with a higher learning curve.

[1] [http://stackoverflow.com/questions/222782/git-vs-perforce-
tw...](http://stackoverflow.com/questions/222782/git-vs-perforce-two-vcs-will-
enter-one-will-leave)

~~~
MikeTLive
you found the same one that i did while editing. if git is great, is it worth
changing an enterprise to use it? when the auditors come, I need to list the
changes on a server. when its an app, the changes to that app. who, what,
when, where, why - reviewer, requestor, approver, author, deployer,
etc.etc.etc. how granular and how far back can i get this with GIT? how solid
is the nonrepudiation factor with GIT? for commits - can i see who else might
be looking at code? for security - can i protect others from getting the code?

~~~
rallison
You bring up some valid questions - thanks. I think you are getting at a few
scenarios where, in fact, perforce is better. I like git, by no means is it
the best solution for all cases.

 _if git is great, is it worth changing an enterprise to use it?_

There are a ton of factors involved in answering that question. A lengthy blog
post could be made trying to answer that.

 _when the auditors come, I need to list the changes on a server. when its an
app, the changes to that app. who, what, when, where, why - reviewer,
requestor, approver, author, deployer, etc.etc.etc._

This depends on how git is setup. In the simple model of everyone on a team
having push access to one origin server that serves as, effectively, the
central repo, and that repo allows force pushes, then yes, this may not
satisfy an auditor. As in, anyone on the team can rewrite history. Of course,
when the central repo suddenly doesn't match up with all the copies everyone
else has, somebody will probably realize that something is amiss.

That said, being a DVCS, it is not hard to setup something where only a few
top level people have push access to the what we'll call the authority server,
and all commits from everyone else has to flow through these trusted people.
Additionally, force pushing can be disabled on the authority server, so no one
person can rewrite history (aside from the people who have direct file system
access to the authority server).

Or, think github - people fork a repo, then submit a pull request. Tons of
people _can_ commit to a repo, but most commits flow through a trusted few.

 _how granular and how far back can i get this with GIT?_

If you are asking history, the git history goes back to the very first commit.
It is also easy to list the entire history of just one file, and more.

 _how solid is the nonrepudiation factor with GIT?_

As with a couple answers previous, it all depends on how git is deployed in
the organization. The answer will vary from none to rather good, depending on
the deployment.

 _for commits - can i see who else might be looking at code? for security_

If you've granted access to someone to be able to pull from your repository,
then no, you can't see who is looking at what. Anyone with pull access will
have access to the entire repo. Want finer grained control here without
resorting to multiple repositories? Then git is not the right vcs. This is
where something like Perforce will win.

 _can i protect others from getting the code?_

In what way? People who already have some access to the repo? See the above
answer. Or Joe Q Public? That is trivial.

\--

Basically, the big area where something like Perforce (or even SVN I believe)
will win is when you need fine grained control over security. E.g. User A only
has access to this subfolder, User B only has access to this other subfolder,
etc.

