Live data from Hacker News

Mercurial 2.9 released

mercurial.selenic.com

21–30 of 79 posts

Re: Mercurial 2.9 released

#21
post #16

The monthly updates always scare me a bit for version control. Is that really prudent?

They're actually very big on backwards compatibility. It's quite straightforward to work with repositories created by old mercurial versions on and communicate with mercurial installs with different versions. The only thing that won't work is features that are only in the newer version.

The real effect of the monthly releases is that bugs get cixed in releases, new features get added, and I get to regularly see all of the awesome activity going on in the mercurial world.

Re: Mercurial 2.9 released

#22
post #2

I would be interested in hearing from people who are using hg still. What is the reasoning? Do you see something in hg that the rest of us don't? Are there specific features of hg that git doesn't have?

I consider hg far more easy to use than git, specially for the most used commands (status, fetch, push). I need to check the docs about how do the damm push each time with github.

My only gripe with mercurial? That everyone else asume git.

Re: Mercurial 2.9 released

#23
I rarely have geeky conversations with anyone (since I don't know any and that is why I hang out here) but I'm genuinely curious:

Why is git more popular than hg? I tried both and hg was generally easier (for me) to pick up. I'm sure it's not JUST because of github.

Re: Mercurial 2.9 released

#24
post #23

I rarely have geeky conversations with anyone (since I don't know any and that is why I hang out here) but I'm genuinely curious: Why is git more popular than hg? I tried both and hg was generally easier (for me) to pick up. I'm sure it's not JUST because of github.

Linus is the reason, I guess.

I tend to think that if Git was written by somebody other than Linus, it wouldn't have gotten so popular. After all, Git was not even envisioned as a VCS [1], and all the usual VC-related functionality has been bolted onto it without a single design vision, which is why we have this clusterfuck of a CLI now.

Sometime after that there was GitHub.

[1]: http://marc.info/?l=linux-kernel&m=111288700902396

Re: Mercurial 2.9 released

#25
post #10

Earlier quoted context omitted.

I use both. I dont think Git 'won' but it is more popular. I suspect many git users dont even know why they use git except because they were told to, they probably never tried hg or know anything about darcs, bitkeeper, etc.

I like git because it stores objects, not diffs and you can recover from almost anything with reflog.

> I like git because it stores objects, not diffs

Now _that's_ a reason to pick a VCS! Would you drop Git if you found out that this is not true [1]?

[1]: http://git-scm.com/book/en/Git-Internals-Packfiles

Re: Mercurial 2.9 released

#26
post #3
post #2

I would be interested in hearing from people who are using hg still. What is the reasoning? Do you see something in hg that the rest of us don't? Are there specific features of hg that git doesn't have?

Speaking for myself: the one specific thing I use every now and then in Mercurial is "hg serve" command. It allows me to serve up my changes to others in an ad-hoc way without needing to set up a repo in the usual places (Bitbucket, Github, etc.). If one needs to set up a local repo hosting service for internal use in a .NET company, there's SCM Manager ( http://www.scm-manager.org/ ), which is free, supports both Hg…

> If one needs to set up a local repo hosting service for internal use in a .NET company,

There's also (shameless plug follows) HgLab ( http://hglabhq.com/ ).

Re: Mercurial 2.9 released

#27
post #19
post #15

Very glad to see this in between all the git monoculture. Yes, GitHub is kind of nice for some things, but git really isn't.

What a contentless comment. One might just as well flatly claim that mercurial isn't nice for anything.

git's CLI design is byzantine and inconsistent, with terms that are both overloaded and underloaded (many commands do multiple, unrelated things while at the same time many common tasks do not have commands). It's very easy for newcomers to place their local repo into a limbo or failure state that they can't get out of without consulting a git guru. git's error messages and man pages are written for its developers, not for its users. git's overall CLI structure maps poorly onto its underpinnings, half-hiding parts and not explaining the rest. Pushing and pulling have really bizarre default behavior that easily confuse those who have not carefully studied how they work.

git is extremely powerful and is, buried underneath its abysmal UI, a thoughtful and elegant work of engineering. However, as a product it's incredibly difficult to explain to other people. Until you've invested a thoroughly unnecessary amount of time learning its gotchas, quirks, and vagaries it is a monumental pain in the ass to use.

(Don't get me wrong, I use git all the time and appreciate its power. I just wish Linus has asked someone else to design the CLI.)

Re: Mercurial 2.9 released

#29
post #27
post #19

Earlier quoted context omitted.

What a contentless comment. One might just as well flatly claim that mercurial isn't nice for anything.

git's CLI design is byzantine and inconsistent, with terms that are both overloaded and underloaded (many commands do multiple, unrelated things while at the same time many common tasks do not have commands). It's very easy for newcomers to place their local repo into a limbo or failure state that they can't get out of without consulting a git guru. git's error messages and man pages are written for its developers, n…

git aliases.

Re: Mercurial 2.9 released

#30
post #23

I rarely have geeky conversations with anyone (since I don't know any and that is why I hang out here) but I'm genuinely curious: Why is git more popular than hg? I tried both and hg was generally easier (for me) to pick up. I'm sure it's not JUST because of github.

Speed and workflow, previously. Mercurial has made up most of the difference in speed, so now git is better for some things ([temporary] topic branch workflow and history clean-up of such branches before merge is more likely to be used by git committers even if hg technically has that now, speed in a few cases, mindshare) while mercurial is better for other things like syntax, or dealing with gigantic repositories -- like Facebook's[1], but only because Facebook engineers decided that functionality was easier to add to mercurial than to git.

[2] https://news.ycombinator.com/item?id=7019673

Post reply on HN