Live data from Hacker News

Mercurial 2.9 released

mercurial.selenic.com

51–60 of 79 posts

Re: Mercurial 2.9 released

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

1) Linux and it's viral tirade on SVN on Youtube.

2) Cargo-cult computing.

3) Very strategic integration with Heroku and Xcode. Both are very important force multipliers. It was initially the Ruby folks they were the champions of Git outside of the Linus kernel devs.

4) Github.

5) Silicon Valley. SV is a very large echo chamber, the fact that Github is in the middle of it gives you an edge. Bitbucket is based out in Australia I think, there was less people to talk to, less good people for hire etc. Back in around 2008, both Github and Bitbucket were terrible.

Re: Mercurial 2.9 released

#52
post #36

I would LOVE to use mercurial. If the concept of a backup bundle was completely removed. When I amend a commit with git, I don't put myself 20 minutes away from recovering that pre-amend commit. If hg comes up with some way to have a flat namespace like git, (ideally with a reflog) I'll be back.

That whole "back up a part of history so that you could undo stuff later" will be gone as soon as Changeset Evolution [1] is ready. An when it's ready, it will be tremendous.

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

Re: Mercurial 2.9 released

#53
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…

That came quite close to happening. Quite quickly after git appeared, several alternative CLI's called porcelains were developed. The most popular was cogito. Git itself quickly stole the nice features from the porcelains withered. At that time only power users used git, so there was little interest in the porcelains and the nicer interfaces were list.

Re: Mercurial 2.9 released

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

At work we have non-devs (mostly scientists) using our repos, and I didn't want to have to teach them git. Mercurial is much easier to pick up IME. With the right plugins enabled, there's not much I miss day to day compared with git.

At home I still use git. In part because of github, in part because I like some of the default behaviour better, and in part because being forced to learn how it works to dig my way out of holes broadens my understanding of DVCSs in general.

Re: Mercurial 2.9 released

#55

Has anyone used this (or something similar)? the Hg-Git mercurial plugin http://hg-git.github.io/

Yes, it works great. If you prefer hg you can push your code to github and get pull requests, etc. from people who only know git.

Re: Mercurial 2.9 released

#56
post #3

Earlier quoted context omitted.

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…

> 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.). You can do the same in git: git daemon --verbose --export-all --base-path=.git --reuseaddr --strict-paths .git/ or git daemon --verbose --export-all --base-path=. --reuse…

Or you can use git instaweb instead?

Re: Mercurial 2.9 released

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

Mercurial gives you complete DAG of history with enough tools (revsets) to filter and view it in any way.

Git lets you peep into the DAG of history through small windows, called 'branches'.

This was the biggest annoyance for me when I tried git. You cannot even ask git for the id of the currently checked out revision, ie if you are not on a branch tip.

And yes, the inconsistent cli is a big turnoff too.

Re: Mercurial 2.9 released

#58
post #40
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.

3 reasons: * Linux Kernel : this means for once, great popularity. Those who commit to the kernel have quite a bit of say and influence in the industry. The tools they use get free marketing just from that. But this actually leads to the next reason --> * Speed : initially git was quite a bit faster. It had been tested and benchmarked day to day on the kernel source tree. hg, bazaar and others weren't as performant b…

> Speed

Actually in 2005 performance was pretty similar and for some workflows hg was definitely faster (patch + commit). Also before packs were introduced git just used massive disk space (hg had smart storage from day one).

Re: Mercurial 2.9 released

#59
post #35

Earlier quoted context omitted.

> 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

I see where he is coming from even if the wording is ambiguous. Git presents the abstraction of storing objects, and diffs are inferred. The exact implementation is beside the point.

But then mercurial is the same, the abstraction is about file content, the diff compression is an internal detail of the storage format like packs.

Re: Mercurial 2.9 released

#60
post #16

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

The monthly releases are bugfix only. New features are released every three months (and release process has an extended freeze where only bug fixes are allowed for a couple of weeks before the release)
Post reply on HN