Live data from Hacker News

Prefer mercurial to git

lists.gnu.org

111–120 of 189 posts

Re: Prefer mercurial to git

#112
post #55
post #6

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

Quite frankly, not sharing GNU's goals is a feature, not a bug. The less the source code is encumbered by onerous political restrictions, the better.

I don't think that you'll find a lot of contributors to GNU Emacs who agree with that stance.

Re: Prefer mercurial to git

#113

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

Because developers spend a lot of their day working with them.

And it can take a significant amount of time getting to grips with a new one you are unfamiliar with.

And you can often quite easily get yourself in quite a serious tangle with complex merges and operations done with VCSs leading to a lot of cursing and hatred for a particular tool.

A pair of shoes is just a pair of shoes, but I'd still quite like a pair I find comfortable, thanks.

Re: Prefer mercurial to git

#114
post #6

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

  I find git's GPLv2-only license to be a disadvantage when
  contrasted with hg's GPLv2-or-later. For example,
  this makes it more awkward to combine git with AGPL code, which is
  something that we reasonably might want to do for web front-ends.
  GPLv3 and AGPL have mutual cross-compatibility clauses with each
  other, but AIUI, GPLv2-only and AGPL don't.
Incompatible in this context mean that "GPLv2 only" is causing more license incompatibilities than gplv2+.

Re: Prefer mercurial to git

#115
post #88
post #53

Earlier quoted context omitted.

git is as prone to bitrot as hg. git doesn't run fsck on the entire repo for each operation, and unless you fsck or clone you won't detect corruption for quite a while. it's exactly the same for hg, which is built on the same hashing concept as git (actually the other way round, as hg came first).

Moreover, Mercurial's storage scheme is built on append-only files, whereas Git periodically repacks its objects, which means that Mercurial actually has fewer opportunities for cosmic rays to hit the bits while they are in motion, and so less chance of corruption.

Most bit rot isn't due to cosmic rays, but rather to decay on the disk itself.

Re: Prefer mercurial to git

#116

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…

I can relate to these comments because when I was a Git user forced to use Mercurial for Firefox development, I initially thought much of the same. I have since come around [1].

Mercurial has come a long way in the last few years. While I used to see repo corruption semi-frequently, I have not seen it once in the last year or so. This can be attributed to bug fixes and less reliance on mq. mq is a giant hack on top of Mercurial's storage model and there were many corner cases in older Mercurials where mq could lead to repo corruption. I use the experimental evolve extension now, but I can't yet recommend that to the masses because it's very rough around the edges. Hopefully in the next 6-12 months.

I strongly disagree with the statement that Mercurial is less flexible than Git. I find Mercurial to be more flexible. If you don't take my word for it, ask Facebook [2]: "Our engineers were comfortable with Git and we preferred to stay with a familiar tool, so we took a long, hard look at improving it to work at scale. After much deliberation, we concluded that Git's internals would be difficult to work with for an ambitious scaling project." The article goes on to describe some key areas where Mercurial is more flexible.

Some things possible in Mercurial that aren't with Git:

* Extending the wire protocol. Git's wire protocol is the exchange of objects (key-value pairs) and refs to said objects. Mercurial's is command-based and you can have client and server talk their own commands.

* Revision sets [3]. Extremely useful feature. See [4] for how I've used this as Mozilla.

* Phases. Mercurial knows when you are changing a published and should-be-immutable changeset/commit and by default prevents you from footgunning yourself.

* Changeset evolution. The mindset about "pushing rebases is evil" has its roots almost completely in limitations of tools. Changeset evolution removes that limitation.

As I wrote at [1], I believe the future of Mercurial is bright. Don't discount Mercurial because of past experiences with ancient versions or because you assume the Git way is the only and right way.

[1] http://gregoryszorc.com/blog/2013/05/12/thoughts-on-mercuria... [2] https://code.facebook.com/posts/218678814984400/scaling-merc... [3] http://www.selenic.com/hg/help/revsets [4] http://gregoryszorc.com/blog/2013/11/08/using-mercurial-to-q...

Re: Prefer mercurial to git

#117
post #44

Earlier quoted context omitted.

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

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

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

Re: Prefer mercurial to git

#118
post #78

Earlier quoted context omitted.

> The GNU/FSF mindset is one of "You're either with us or against us" - but over here in the real world, things are not so black and white. That isn't in the least true. You should be very careful when trying to decode someones mindset because now you are putting words in someones mouth that never was there in the first place.

I don't thinks words are being put into anyone's mouth, what was said was quite clear: > while Git is made by anti-GNU people who do not believe in free software As stated in above comments I would find it hard to believe Linus would not say that GNU is a valuable asset or software built strictly promoting GNU/FSF principles is bad ... but he's been labeled as anti-GNU for writing software that has a more permissible…

> but he's been labeled as anti-GNU for writing software that has a more permissible license

No. he has been labeled as anti-gnu because of torvalds own statement like:

  "So I'm pretty well-known for not exactly being a huge fan
  of the FSF and Richard Stallman"
  
  "Linux from the very beginning was not about the FSF ideals."
I would not directly call it anti-gnu, but neither is he friendly. He can also not be directly called truly neutral given the number of negative comments he has made about projects and work.

Re: Prefer mercurial to git

#119

Earlier quoted context omitted.

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

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

note that if you use queues it works okay ;-)

Re: Prefer mercurial to git

#120
post #25
post #6

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

Summary of main arguments: Jordi Gutiérrez Hermoso: [...] main argument in favour of hg is not technical, but rather social. For GNU, I think it is far more important to support a project that aligns with GNU's aims [...] GPL2+ Reply by Eric S. Raymond: +1. And I say that as someone who *likes* hg and wishes it had won. Repeating the bzr mistake would be stupid, stupid, *stupid*. Edit: Raymond replied to Kastrup who…

Off-topic, but that's not how Spanish and Latin American names work. His "primary" last name is Gutiérrez, not Hermoso.
Post reply on HN