Comment by durin42 | Hacker News Reader

Comment by durin42 | Hacker News Reader

Parent Full thread

I feel like I have to respond to some of these, as the response is kind of a lot of out of date information. Here goes:

forest is actually obsoleted by the built-in subrepo feature.

bookmarks are always on now - the extension is now a no-op.

transplant is (mostly? it was for my needs) obsoleted by graft - a core command that's smarter.

mq I don't personally use anymore, because of bookmarks, rebase, and histedit

hsitedit - ships in the distro now, off by default (see below)

inotify - hg status /is/ fast. This makes it stupid fast even on absurdly large working copies (extension is subject to some race conditions though. I don't recommend it. bos is doing some work to make this faster w/o the extension).

acl: I think you're missing the point? It lets you have certain users allowed to push mods to a subset of files /without/ having to resort to multiple repositories (which are a hassle, even with submodules or subrepos).

Also, there's a reason some of these features are off by default - most users shouldn't be touching them. Having a barrier to using them has been (in my experience) a real benefit when trying to train newbies.

Also, some of us think pager is a misfeature - it drives me bonkers anytime git "helps" me in that way.

I didn't notice the date on the answer. Someone with StackOverflow edit powers really ought to go back and update the response. It's nice to see that Mercurial is integrating these things into the core. My experience with Hg was over 3 years ago, before this answer was written.

RE: acl -- I understand it. I just don't really see a need for it because I prefer pull-requests and decentralized decision making. I truly dislike the "commit bit" culture that accompanies centralized repositories and acls seems to import some of that culture. I'm a big believer in better to beg for forgiveness than to ask for permission, and therefore I'd much rather say "Hey, I changed these files, you should pull from me" and if I fucked up, you can call me an idiot and I'll have learned something. Maybe put a README in the special directories! Then again, I feel similarly about method access control in C++ & Java vs Python. Python's underscore prefix for private bits is enough to stop me from screwing up, even though I can dig in and fiddle with private stuff if I actually know what I'm doing and no compiler is going to stop me.

> most users shouldn't be touching them

Mercurial is clearly designed for easy of learning. That's a worthwhile goal, and I think that it's great at that. As I mentioned, I started with Mercurial. It's a great offramp from SVN and onramp to DVCS.

However, my version control system gets more use than any software on my system, minus my text editor! It's worth learning. It's worth investing in. And it's worth having a sub-par beginner experience to optimize for the experts.... for me. I'd recommend Hg to any team looking to get started with DVCS where there is a mix of stronger and weaker devs and you're sure to have people who are going to have difficulty understanding Git. Hg is easy enough for beginners and flexible enough for experts. Git, however, is tuned for experts. I know quite a few people who have worked with both, and they all prefer Git... in time.

I work with both extensively, and still loathe git.

note: I work on the guts of VCS for a living.

I'm the author of the original SO answer. I've updated the entry to reflect info posted here and on SO. Let me know if there's anything missed.

Reply on news.ycombinator.com