Live data from Hacker News

Prefer mercurial to git

lists.gnu.org

61–70 of 189 posts

Re: Prefer mercurial to git

#61
post #22

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

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

This is it exactly. A lot of people miss this with hg. hg bookmarks are the equivalency to git branches. hg branches are "permanent." So you have, say, 'dev,' 'test' and 'stable' branches. Then you do hot-fixes and feature development on bookmarks, and merge them back into the branches.

It's a beautiful thing, really

Re: Prefer mercurial to git

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

What was stated was "anti-GNU". Decoupling GNU from the FSF is weird.

Re: Prefer mercurial to git

#63

Earlier quoted context omitted.

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

What was stated was "anti-GNU". Decoupling GNU from the FSF is weird.

That still doesn't wash. It is quite possible to believe that the GNU project and what's associated with it (FSF) is a net positive while disagreeing with some of the actions of its founders or boosters, or some of their ideology.

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.

Re: Prefer mercurial to git

#64
post #7

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…

As stated by the documentation, those numbers are purely a convenience feature for when you don't want to give the actual revision hash to a command. The latter is what you have to do in git anyway.

Re: Prefer mercurial to git

#65
post #37
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.

A slight exaggeration, but yes, that's quite close to the OP's argument (Git is GPLv2 and will not change; Hg is GPLv2+ and therefore closer in spirit to GNU's goals and a GNU project like Emacs should favor GPLv3 and AGPL tools). Luckily, that particular argument is thoroughly rebutted downthread. Choice quote: "Emacs shot itself in this foot already" by choosing Bzr, GNU's blessed VCS, for such political reasons. (…

Hg is GPLv2 or later, which (importantly) permits incorporation of Hg code in GPLv3 and AGPL codebases, but is not quite the same as it being GPLv3.

Re: Prefer mercurial to git

#66

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…

> but I found it to be incredibly frustrating already knowing git.

From my understanding, the terminology and behavior of Mercurial is more in-line with other SCMs out there (like SVN), while Git seems to do things a bit differently. A lot of it is terminology differences or default behavior for various commands.

> I found it to be slower, less flexible,

Mercurial should be about the same speed as Git now adays. I'd be interested to hear what parts of HG you thought were slow. Also, for flexibility, Mercurial disables a lot of more advanced features by defaults (anything that could get a developer in trouble or mess with history). All of the extensions that ship with Mercurial are officially supported and can be used if you want that functionality.

> prone to permanent repository corruption

I'd be interested to hear if you ever found out what caused your problems. Mercurial has a page talking about this [0].

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

For almost all features, I'd totally agree. There are 3 things in Mercurial that I see as an advantage over Git. (1) named branches (every commit on the branch will be tagged with the branch name). (2) LargeFile[1] extension for handling very large files you don't want people having to pull, though this breaks DVCS concepts. (3) A future feature that looks really promising, ChangesetEvolution[2], that will basically allow history rewriting that can be pushed to others.

[0] http://mercurial.selenic.com/wiki/RepositoryCorruption

[1] http://mercurial.selenic.com/wiki/LargefilesExtension

[2] http://mercurial.selenic.com/wiki/ChangesetEvolution

Re: Prefer mercurial to git

#67
post #10

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…

Funny, at my company it is the oppositive. If you give the developers the choice, they would drop git and go back to mercurial.

Then why not switch to mercurial?

Re: Prefer mercurial to git

#68

Earlier quoted context omitted.

What was stated was "anti-GNU". Decoupling GNU from the FSF is weird.

That still doesn't wash. It is quite possible to believe that the GNU project and what's associated with it (FSF) is a net positive while disagreeing with some of the actions of its founders or boosters, or some of their ideology. 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 still doesn't wash. It is quite possible to believe that the GNU project and what's associated with it (FSF) is a net positive while disagreeing with some of the actions of its founders or boosters, or some of their ideology."

A fair point. Picking licenses that explicitly forbid incorporation of your code in modern GNU projects is a little more than that, though.

'The GNU/FSF mindset is one of "You're either with us or against us"'

I don't think that's quite as true as you think it is.

Re: Prefer mercurial to git

#69
post #36

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, a…

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

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

Re: Prefer mercurial to git

#70
post #53

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…

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

Mercurial was announced on 2005-04-19 and git on 2005-04-07, so no Mercurial was not first.

Edit: Monotone is older than git though.

Post reply on HN