
Prefer mercurial to git - arunc
https://lists.gnu.org/archive/html/emacs-devel/2014-01/msg00343.html
======
spellboots
I was forced to use mercurial for a few years at work and I really hated it.
Sure it has a better learning curve than git (or did) but I found it to be
incredibly frustrating already knowing git.

In addition, I found it to be slower, less flexible, and prone to permanent
repository corruption - yes, in git you do see repo corruption but because of
the cryptographic nature of git objects you know immediately. HG will (did?)
happily let you work away at a corrupted repo for weeks until a fresh clone
was attempted and the dreaded repo corrupted message killed development for
days until the problem was painstakingly manually fixed.

This is just personal experience and a lot of it comes down to taste, but IMO
if you are already proficient with git there is absolutely nothing about
mercurial that is preferable and some considerable downsides I have been
subjected to.

Disclaimer: This was a few years ago now, perhaps the project is more mature
than it was.

~~~
hawkharris
I'm interested in your comment about the _cryptographic nature of git
objects._ I know that hashes are used to identify commits, but I'm not sure
how Git uses cryptography elsewhere — e.g. to check the integrity of repos, as
you said. Can you explain this aspect in more detail? (Not being
argumentative; just curious.)

~~~
rmetzler
Committers are able to sign their commit with their GPG key.

Edit: I was wrong and changed all the words

~~~
Hello71
Not by default it isn't. And git uses GPG, not SSH keys.

~~~
rmetzler
You're right, I was wrong. I'm sorry.

------
copx
You should have linked the first post in that thread. It explains what the
whole thing is actually about:

[https://lists.gnu.org/archive/html/emacs-
devel/2014-01/msg00...](https://lists.gnu.org/archive/html/emacs-
devel/2014-01/msg00238.html)

Tl;dr: Mercurial is a free software project sharing GNU's goals, while Git is
made by anti-GNU people who do not believe in free software and has an
incompatible license.

~~~
Karunamon
>while Git is made by anti-GNU people who do not believe in free software and
has an incompatible license.

WTF? Git is GPLv2 - the exact same as the Linux kernel. A great many
developers are avoiding v3 due to the changes it made. And "anti-GNU people"
is just a lame insult.

~~~
copx
The people who avoid the GPL3 do it because they do not share the goals of the
GNU project. The GPL3 expresses the same philosophy as the GPL2. GNU released
a new version only because companies discovered a loophole (a bug if you will)
in the GPL which allowed them to build non-free (as in GNU) systems based on
GPL software. GNU was founded to fight such systems.

However, Linus Torvalds (Linux and git) has no problems with non-free at all
and in fact wanted to support the production of such systems. Like many users
of the GPL2 he never actually shared the goals of GNU.

Git's license was deliberately chosen to support the building of non-free
systems. According to GNU ideology that is evil. If you are a GNU contributor
you are not supposed to even link to non-free solutions. So yeah, of course
the hardcore GNU ideologues do not like git or the people behind it.

~~~
Karunamon
Not agreeing with the FSF's rather dogmatic stances does not make you "anti-
free-software". Having no problem with closed source does not make you "anti-
free-software".

(Except in the eyes of zealots, but who cares about them?)

~~~
belorn
> Having no problem with closed source does not make you "anti-free-software".

While true, its a bit odd of a statement. The following statements are also
equally true:

Having no problem with deforestation does not make you "anti-
environmentalist".

Having no problem with Ku Klux Klan members does not make you "anti-
tolerance".

Having no problem with murder and theft does not make you "anti-government".

Except... if you are helping others in deforestation, the environmentalism
movement will dislike you. If you are helping the Ku Klux Klan, the tolerance
movement will dislike you. If you are helping murders, the government will
lock you in.

So why do you label FSF as zealots for disliking actions that helps those that
want to threaten users with lawsuits and prevent new versions of software for
being used, shared or modified?

~~~
Karunamon
>So why do you label FSF as zealots for disliking actions that helps those
that want to threaten users with lawsuits

Without even getting into the broken-ness of your analogies, being anti-DRM
and anti-patent-abuse and so on is one thing. Calling someone evil because
they don't publish the source of their app is quite another. According to
their dogma, if I write a program and don't release the source code, I have
perpetrated some horrible thing on the world. _Regardless of any other
interaction I might have with a user of my app._

Pardon my French, but that's fucking idiotic.

And even if I do release the source, I'm in the wrong if I don't release it
under their pet license of choice. (Though not exactly "evil".)

What if my goal is to just see my code in use, not get embroiled in political
battles? BSD is a de-facto more permissive license. What if I don't care if
some corporation comes along and takes my code and releases a product based on
it? Cool! I've helped the world somehow! And people who want to use my code
don't have to get involved in GPL politics and drama!

My problem with the FSF is that they assume they are Right, their stance is
Right, and anyone who disagrees or dissents is Wrong. Hence dogma. I know
religions with more ideological tolerance.

~~~
belorn
> What if I don't care if some corporation comes along and takes my code and
> releases a product based on it? Cool! I've helped the world somehow!

Say you developed a program that keep tracks of group of people. The Ku Klux
Klan use it to track down black people, and the anti-tolerance movement use it
to track Ku Klux Klan. You helped the world and the anti-tolerance movement
should be happy right? If they would prefer that the tool could not be used by
the Ku Klux Klan, then they are evil zealots with no ideological tolerance.

Pardon my French too, but that's is fucking idiotic.

> And people who want to use my code don't have to get involved in GPL
> politics and drama!

That is a very dishonest statement. People can use Debian without becoming
involved with politics and drama. I will state fact-less that most people who
use GPL have not becoming involved with politics and drama.

> I know religions with more ideological tolerance.

Like BSD proponents I suppose? You own comment stated BSD as the right choice
and anyone who disagrees is wrong. Maybe instead of preaching tolerance, you
practice tolerance of people that disagree with you. Is it not more tolerant
behavior avoid derogatory terms?

~~~
Karunamon
>Say you developed a program that keep tracks of group of people. The Ku Klux
Klan use it to track down black people, and the anti-tolerance movement use it
to track Ku Klux Klan.

Stop it. You're basically engaging in a not-hitler version of Godwin's Law.
And it's not even relevant, since the GPL is only about source code, not about
whatever that code is used for. In your completely arbitrary and fucked up
example, as long as the KKK released the source code to their tracking app,
the GPL has nothing to say.

>You own comment stated BSD as the right choice and anyone who disagrees is
wrong.

No, I said BSD is a de-facto more permissive license. It objectively has fewer
restrictions on a developer than the GPL. Read what I said, not what you want
me to have said, please.

~~~
belorn
What you said was:

> BSD is a de-facto more permissive license. ... And people who want to use my
> code don't have to get involved in GPL politics and drama!

So yes, you statement was an "BSD as the right choice, GPL is the wrong
choice". If you actually want to be tolerant of people right to license what
they want, you should not badmouth their choices when they don't pick the same
as you.

> as long as the KKK released the source code to their tracking app, the GPL
> has nothing to say.

I have said nothing about the license. I have said that the anti-tolerance
movement would have something to say when that program helps KKK. I also said
that it is an understandable reaction from the anti-tolerance movement. They
are allowed to be both thankful for the help they got, and scornful about the
fact that it is helping KKK.

This is the same complain when FSF dislike when proprietarization is made
easier by other peoples license choices. They are thankful for the help, and
also scornful about the fact that it makes their goal harder to achieve. If
you don't find that relevant because "its a license" or because of godwin,
then that is up to you.

~~~
glogla
I wonder why is it always the anti-GNU people who are behaving like raging
teenagers? I have never heard FSF advocate call people zealot or "fucking
idiotic" for preferring other license, but the other way around it's a rather
common occurrence. I don't want to generalize, but I guess it has to do with
they kinds of people who like and dislike GNU.

The day when people will say "oh I like BSD better" instead of "OMG BSD is
much more free you are fucking idiots for liking GPL" will be a good day.

~~~
Karunamon
Who'd have thought? Some people don't like being called "evil" for what _they_
choose to do with _their_ code.

~~~
belorn
Who has ever called BSD "evil"? They do have a devil icon (a point
Uncyclopedia is having fun with), but who in their right mind would call BSD
evil as a concept?

Proprietary software is sometimes called evil by the free software movement.
It is after all the very model that the movement was created to destroy. The
environmentalist movement will also call deforestation "evil", as well as
anyone who dump oil into the oceans.

BSD however are not Proprietary software. Is it possible, that this discussion
is not really about BSD, but rather you using it as a front for your own
interesting in proprietary software model. In that case, you are being very
dishonest.

~~~
Karunamon
I wasn't even talking about BSD. I was talking about the FSF's propensity to
throw around words like "evil" when discussing non-open-source software.

The whole BSD thing is a misunderstanding by you and a guy upthread. I never
stated anything about BSD's superiority, only that it is an _objectively more
open license_. GPL has _objectively more restrictions_ and de facto associates
you with a group that many don't want to be seen as part of.

------
nailer
Context? This just seems to be a post from a Mercurial/Hg advocate.

Mercurial could be 10% better than git, but unless it's 500% better, it will
never displace it.

~~~
hyperbling
emacs is moving off of bzr.

------
ufmace
I've been meaning to do a blog post about this for a while, but I've tried
both, and so far, I prefer Git because of the way it treats branches. Git
seems far friendlier to the workflow of just doing stuff, and deciding how you
want to commit it later. In Git, it's easy to work for a while, then decide
you have 3 commits worth of changes, and one of them really ought to be in its
own branch, and commit it all like that. The code that you branched off stays
out of your mainline for now, but is easy to switch back to and work on some
more. At any time, you can easily delete the branch, and it all effectively
disappears, push it somewhere else for somebody else to work on, or merge it
back into main when it's ready. Well, merging might be tricky if you wait too
long, but you get the idea.

Where Mercurial falls short to me is that if you create a branch in your main
repository like that, then it never goes away as far as I can tell. What
Mercurial really wants you to do is clone your repo, and do that work that
would be a Git branch in the clone. But to do that, you have to start with a
clean repo, actively decide you want to create a new branch/clone, clone your
repo, and only then start doing that work in the clone. If you've already done
some work, and then decided that a piece of it ought to be branched off, then
your workflow is pretty messy - you have to clone with the work uncommitted,
then manually move the changes over to the clone and commit them there. And
switch any working directories you might have open to the clone directory to
work in it.

Yeah, no thanks, I'll stick with Git.

~~~
masklinn
> Where Mercurial falls short to me is that if you create a branch in your
> main repository like that, then it never goes away as far as I can tell.

`bookmarks` will do that. Or you can use unnamed heads and track them
manually[0] (that's essentially what bookmarks — and git branches — do).
"Detached heads" are not a thing in mercurial, heads don't have to be named.

[0] obviously there's nothing to track if you're just going on a short
tangent, just commit your stuff, and go back to the original to merge if it
was a good idea or forget if it was not. And yes you can create a bookmark
"after the fact" e.g. do half a dozen commits, realise that it's going to take
longer than you thought and create a bookmark for the current experiment on
the tip.

~~~
ufmace
I hadn't heard of that, and it does sound like a nice feature, but it still
seems a little hacky compared to Git branches. At best, it would be as good as
them, but then why not stick with the original?

Oddly enough, I find myself liking the simplicity of Git here. You can do
pretty complex stuff with it, but having only one type of branch seems to help
some. That, and the local-only stashsets, which seem to be intentionally kept
as simple as possible. In Mercurial, you have named branches, unnamed
branches, cloned repos, bookmarks, maybe some other stuff that I don't know
about, and I'm not really sure how they all interact and what's used for what.

~~~
masklinn
> I hadn't heard of that, and it does sound like a nice feature, but it still
> seems a little hacky compared to Git branches.

It's exactly the same thing git branches do. If it seems hacky, it's also
hacky in git.

> At best, it would be as good as them, but then why not stick with the
> original?

Stick with what original? The originals in mercurial are branches (where the
branch name is part of the commit metadata and thus of the repository's
history forever, save for history rewriting) and "anonymous heads".

Then users clamoured for transient (movable, renamable, deletable) git-style
branches, so bookmarks were added as an option.

> cloned repos

Erm… you can also clone repositories in git.

> I'm not really sure how they all interact

At the end of the day, it's all commit DAG.

~~~
ufmace
> It's exactly the same thing git branches do. If it seems hacky, it's also
> hacky in git.

I more meant that it seems hacky to add a feature that's mostly-sorta like Git
branches to Mercurial now.

> Stick with what original? The originals in mercurial are branches (where the
> branch name is part of the commit metadata and thus of the repository's
> history forever, save for history rewriting) and "anonymous heads".

I meant original as in Git vs Mercurial. Like if you want Git-like branches,
then why not just stick with Git?

> Erm… you can also clone repositories in git.

Yeah, you could, but I've never seen anybody recommend cloning a Git repo on
the same computer for the purpose of separating out work from the main branch.
At least for a while, this seemed to be widely recommended way of separating
code out in Mercurial.

Where things get kinda weird - in Git, if you want to commit code somewhere
that doesn't go into main just yet, there are only 2 options - branches and
stash, and stash is explicitly meant to be a very short-term, local thing,
since you can't really share them easily and they aren't really part of the
commit hierarchy. That makes things simpler, as you never have to wonder what
the right feature to use is for keeping separate work somewhere and sharing it
with other people. You can create complex structures with branches, but at
least there's only one 'type' of thing to keep track of.

I'm not as familiar with Mercurial, but for ways to keep temporary work
somewhere, it seems we have named branches, anonymous branches, bookmarks,
cloned repos on the same system, and apparently shelve too. According to this
guy[1], the workflows for sharing bookmarks around don't seem to be fleshed
out all that well either. So how do I know which one to use for what tasks?

[1] [http://www.kevinberridge.com/2012/05/hg-bookmarks-made-me-
sa...](http://www.kevinberridge.com/2012/05/hg-bookmarks-made-me-sad.html)

------
jefftchan
Relevant: Facebook migrated from git to hg awhile back.

Here's a blog post on how they are scaling hg for their monolithic repos
[https://code.facebook.com/posts/218678814984400/scaling-
merc...](https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-
facebook/)

~~~
voidr
And by scale they really mean swapped out whole parts of hg, which they could
have done with git as well.

------
leobelle
My biggest issues with hg are that hg's revision numbers aren't synchronized
across instances, they are local only[1] making them kind of useless, you
can't easily have local branches[2], and it stores changesets instead of
objects.

I've ever seen a convincing argument to choose hg over git. Sure you can do a
lot of things with it and I'm sure it's perfectly fine to use, but if you know
git, and you like git, there's no reason to switch. What does hg have that
makes it better than git that you should give up git? Popularity is what git
has over hg. Someone using git will probably never have to spend anytime
worrying about learning hg, but an hg user will have to become familiar with
git because git is used everywhere nowadays. So my recommendation to people
new to versioning systems is to pick git. I can't for the life of me
understand why someone would pick hg for an open source project unless they
wanted to throw learning curves and barriers at developers, or they just
really really liked hg (probably because they chose it over git a long time
ago).

[1]
[http://mercurial.selenic.com/wiki/RevisionNumber](http://mercurial.selenic.com/wiki/RevisionNumber)

[2] [http://stackoverflow.com/questions/8995598/can-i-mark-a-
bran...](http://stackoverflow.com/questions/8995598/can-i-mark-a-branch-as-
not-going-to-push)

~~~
pjmlp
> What does hg have that makes it better than git that you should give up git?

Better user experience out of the box for Windows shops.

This might change with Microsoft's adoption of git for TFS, but you won't find
many appraisals for git at my workplace. Many people still miss hg.

~~~
Karunamon
You mean tortoiseHG? There's tortoisegit as well. And the first Windows-only
proprietary client I could find supports both systems (Smartgithg:
[http://www.syntevo.com/smartgithg/](http://www.syntevo.com/smartgithg/))

~~~
pjmlp
No, I mean the whole experience.

Mercurial being Python based has less UNIX feeling than Git on its workflow
experience.

Plus there are better plugins for Visual Studio integration available then for
Git.

~~~
wmgries
Isn't git built into Visual Studio?

~~~
pjmlp
If you have the 2013 version.

------
sixthloginorso
Why are people sweating small stuff like version control systems? How can you
be a fanboy of a thing that keeps track of branches and patches. It's only
incidentally related to Software development, you shouldn't feel as if a limb
of yours was amputated if you \ _gasp\_ had to use a different one for another
project.

It's like using a different mail client or a different bug tracker; it doesn't
affect what you can express or how can you build a program. It's just _Version
Control_.

~~~
harel
That's true, in a way, until someone tries to force CVS on you. Yes they are
all sideline tools but once you get used to something, its the best thing in
the world, until you get used to something else. Change is great, but not
quite appreciated enough.

~~~
ygra
At work (where my script to convert all of our projects from CVS to Hg is
complete for almost ¾ of a year now) I now resort to a hacky PowerShell script
that allows me to work locally with Hg and then push selected revisions to
CVS. Mostly because I fear that we won't ditch CVS for quite a while and when
we do I'm probably the one to blame for lost developer productivity while
we're coming to grips with a new tool.

~~~
harel
So many wrongs in one comment. The fact you believe you'll be blamed for dev
productivity loss is just not right. Blame? The fact you have to write scripts
converting from one source control to another is not good, the fact you resort
to hacky powershelling is scary. I wasn't even thinking the "are they still
using cvs in 2014" even but I guess I should have. "blame" should exist in
source control systems only.

~~~
ygra
Actually I was agreeing to your point that at the time when CVS is used
version control is no longer "just a tool" but a PITA.

I'm the one who suggested conversion to a newer system, so when the other
developers need to re-learn and lose a week of productivity that way it _is_
my fault, to some extent.

My conversion script is essentially just automating creating cvs2hg config
files for a number of CVS modules (and cleaning up before/after conversion)
because our CVS repo is a few GiB in size, containing everything that ever
existed (and plenty of things beside that) so a 1:1 conversion isn't that
ideal, especially because it will lead to frequent (harmless) merges. But to
developers with a CVS background merges are _scary_.

My cvshg PowerShell script is based around
[https://wiki.mozilla.org/Using_Mercurial_locally_with_CVS](https://wiki.mozilla.org/Using_Mercurial_locally_with_CVS)
and [http://pavelchikulaev.wordpress.com/2012/04/09/using-
mercuri...](http://pavelchikulaev.wordpress.com/2012/04/09/using-mercurial-
locally-along-with-outdated-companys-cvs/), but tailored to how I use the
tools. It allows me to commit happily locally and histedit later when I need
commits I can actually share with others.

~~~
harel
That's different then, I agree. I read your original comment as if you're
tasked with something and then expect to be blamed for it.

------
zobzu
I use Git and Mercurial daily. They're both ok. However.. I prefer Git to
mercurial, mainly because:

\- Git is noticeably faster for all operations (yeah, specially if you don't
use GitHub for pull/push as they're slow as hell ;-)

\- Git has sensible default settings, for example, git log is easier than hg
log|less. Similarly, git show HEAD^ is easier than hg log --patch --rev tip.
(Both are easier to remember, type, and keep the logic across the tool).

\- Finally, Git handles everything in a generic fashion. Want to make a test
branch and play around? git branch blahtest and play. With hg, you have to use
queues, and weird commands such as qpop, qremove, qseries, qnew <= this is
very confusing to newcomers. Basically, I feel like Git knows how to KISS
better than Mercurial.

~~~
masklinn
> Git has sensible default settings, for example, git log is easier than hg
> log|less.
    
    
        cat >> ~/.hgrc
        [pager]
        pager = less -FRX
        [extensions]
        pager=
    

There, I fixed it.

> Similarly, git show HEAD^ is easier than hg log --patch --rev tip

Wait, what? Those commands do completely different things. What are you trying
to do?

Furthermore, the assertion that `git show` is "easier" than `hg log` seems odd
on its face, why is it easier to have two different commands to see the same
thing, with the only difference being the length of the revision set? (yes I
know `git show` can also show other objects, but that's now how you used it
here).

> Want to make a test branch and play around? git branch blahtest and play.
> With hg, you have to use queues

Uh… no. You can create a bookmark, or just commit stuff (hg has no prohibition
against what git calls "detached heads", they're just anonymous branches).

You have to use MQ if you want to do quilt-type things. Used to be you also
had to use it if you wanted to perform extensive history-rewriting, but that
hasn't been the case for a few years now.

~~~
michael_storm
> There, I fixed it.

GP's point was about defaults, not what you can configure. Even being somewhat
familiar with hg, I didn't know about the "pager" extension.

> `git show` does not show a patch by default[...]

It does for me, with git 1.7.9.5.

> (hg has no prohibition against what git calls "detached heads", they're just
> anonymous branches)

I have never understood why this is useful. Why not just name your heads
something, anything? I wouldn't otherwise care, but I always seemed to end up
with mysterious heads from who-knows-where left behind by long-ago merges.

~~~
masklinn
> GP's point was about defaults

Granted, but he then describes the difficulty of typing `hg log | less`. And
defaults cut both ways, I still can't fathom why `git log HEAD` would display
the whole repository history.

> It does for me, with git 1.7.9.5.

Doesn't for me with git 1.8.5.4. Regardless I removed that part since it's not
the gist of the issue and the official documentation asserts it should.

> I have never understood why this is useful. Why not just name your heads
> something, anything?

Why is a meaningless name better than no name at all? Why is git's default
behaviour of losing unnamed heads altogether better than just leaving them
alone?

~~~
michael_storm
> And defaults cut both ways, I still can't fathom why `git log HEAD` would
> display the whole repository history.

I don't know why that's part of the defaults discussion, but okay.

> Why is a meaningless name better than no name at all? Why is git's default
> behaviour of losing unnamed heads altogether better than just leaving them
> alone?

Why would you give a meaningless name? That's a red herring. Do hg users just
memorize which head is which?

Mercurial users seem to get hung up on detached heads a lot. They seem to be
part of the Mercurial workflow in a way that I've never really understood. But
git's detached heads are at least created when I expect them to be, are easily
deleted, and are easily saved.

Mercurial's detached heads (or whatever they're called) want me to either
merge them (why would I merge commits that popped up out of nowhere?), or
close them as described in
[http://stackoverflow.com/questions/3688263/mercurial-
beheadi...](http://stackoverflow.com/questions/3688263/mercurial-beheading-a-
head) (apparently causing these mysterious heads to be saved forever). I much
prefer a DAG with labels, instead of all this state specific to Mercurial that
I have to manage.

~~~
ufo
> Do hg users just memorize which head is which?

Its not that bad if its only a couple of commits deep since you can look at
the commit messages for context. And if you are using a gui like tortoiseHg
then reading a commit message is basically the same amount of work as reading
the bookmark name.

And if you really want to add a name you can add one, you just don't
necessarily need to.

------
jordigh
This is a great blog post about Mercurial and git:

[http://gregoryszorc.com/blog/2013/05/12/thoughts-on-
mercuria...](http://gregoryszorc.com/blog/2013/05/12/thoughts-on-
mercurial-%28and-git%29/)

tl;dr: "If you take anything away from this post it should be that Mercurial
is a flexible and agile tool."

------
perfunctory
Mine might be a very unpopular opinion, but I couldn't care less about
different kinds of (D)VCS. I've got a feeling that recently I, and other team
members, spend more and more time on branching, rebasing, cloning, merging
etc. and less time on actual code writing.

~~~
levesque
Given that you "spend more and more time on branching, rebasing, cloning,
merging, etc. and less time on actual code writing", shouldn't you care _more_
about the different kinds of VCS?

Seems having the right tool should be important.

------
doughj3
> I don't get this argument. Windows and Mac OS X are also more popular; does
> this mean we shouldn't use any other OS because all of the cool games are
> almost exclusively developed on Windows?

Seems like that isn't the same situation. Rather the author should have asked
" Windows and Mac OS X are also more popular; does this mean we shouldn't
restrict developers to using a non-Windows, non-OS X system?" and the answer
is quite simply "no, you shouldn't". Choosing a VCS means every needs to use
that VCS. The same is not [necessarily] true for which operating systems can
be used for development.

------
cbhl
A lot of these arguments seem to stem about whether git or hg is better, which
seems about as useful as arguing vim/emacs or Windows/Linux/OS X -- it depends
on what you need and what you already know.

If you're okay with using closed-source services, Fog Creek's Kiln allows you
to have repositories that can be accessed with both git and hg;
commits/branches/bookmarks in one will show up in the other automatically.

It seems to me that this argument could be solved if someone went and built a
F/OSS equivalent that did the same thing for the emacs devs.

------
octo_t
One of his last points seems to be incorrect (or I'm misreading him).

    
    
      One that I like that replaces my most frequent usage of magit is crecord: interactively select hunks for committing.
    

this is literally 'git add -p', and the -p flag can be passed to a load of
different git tools to have this functionality?

~~~
stevelosh
You're misreading him. 'hg record' is like 'git add -p', but 'hg crecord'
(note the c) is a curses interface:
[https://bitbucket.org/edgimar/crecord/wiki/Home](https://bitbucket.org/edgimar/crecord/wiki/Home)

------
fiorix
Seems like discussing religion or politics to me.

------
moron4hire
A lot of this just seems like the GNU and FSF being anti-Torvalds, an
extension of their clash over the naming of [Linux|GNU/Linux] issue.

~~~
lukeschlather
This is about Torvalds being anti-GPLv3.

~~~
moron4hire
potato, potahto

------
blueskin_
Wait, I thought the whole reason they are ditching bzr is that nobody uses it.
Why move to mercurial for the same problem?

------
lukasm
For 99% devs out there these tools boils down to pretty much the same. UPS of
git is Github and Linus

------
koobarbara
These kinds of posts are on the same level as programming language bashing
posts.

