What are the Best hg/Mercurial Extensions? | Hacker News Reader

What are the Best hg/Mercurial Extensions?

stackoverflow.com

17 pointspooriaazimi11 comments

I've written about Hg & Git before here on HN. Primarily, my argument was that Hg was easy and Git was simple (in the way Rich Hickey defined those terms). I started with Hg, but moved to Git, and I'll never look back. The top answer here is like a cheat sheet to why: Git has nearly all of those plugins baked in. This guy has moved from Mercurial to Mercurial in Git mode... He might as well just switch to git proper!

Standard git distribution, all enabled by default:

color: standard config

pager: on by default

fetch: pull/fetch/merge/rebase distinction in git

graphlog: log --oneline --graph --decorate

hgk: gitk

bookmarks: standard branches

record: normal use of the index

extdiff: difftool

share: standard clone behavior on a local file system

mq: standard usage of branches and rebase

transplant: cherry-pick and rebase

rebase: built in

inotify: status is already fast... not sure why I'd need this

shelve: stash

attic: stash

acl: use multiple repositories & submodules

histedit: rebase -i

forrest: submodules

Some assembly required:

notify: .git/hooks + sendmail

bigfiles: git-annex

You've written about this before? Please stop! This is a great example of some of the worst kinds of advocacy. You showed up to an article about the technology you don't like to pimp the technology you do like, just to derail the conversation we could be having. Does this Stack Overflow question smack of trying real hard to get you to stop using Git? No, so why are you even here?

Your whole point is making a big deal out of something very trivial. These plugins are all core plugins for Mercurial too; the distinction between "core plugin" and "baked-in" is one line of configuration to simply list the plugin name. It's equivalently not "baked in" as your "some assembly required." These plugins are not on by default only because many people don't need to be distracted by them, and those that do wish to use them will have no trouble adding one line to a single configuration file. Learning a whole different SCM is a lot of work to avoid adding one line to a configuration file, don't you think?

There isn't a Mercurial user alive who isn't thoroughly and completely aware of Git and all of its magical specialness, thanks to assholes like you who show up to all of our conversations to proselytize us. Please stop patronizing us with these tired arguments—you're turning us into a persecuted minority, and nobody drags out a fight like a persecuted minority.

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

I work with both extensively, and still loathe git.

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

Good evening, friend, do you have a moment to talk about Jesus? Because with pushy, in-your-face evangelism techniques like yours, I think you'd make a great messenger for Christ.

Or, you know, you could be content with not trying to convert everyone you meet, like a decent human being.

I'm sure the OP did that in good heart! He didn't mean to be an overzealous git advocate, just sharing his experience and why he switched... I switched to hg because I was tired of `git diff --cached` and `git update --force` (or `git revert --hard HEAD` or whatever the hell it was you do when you want to ignore local changes).

Plug for my own hg-github extension: https://github.com/stephenmcd/hg-github

It's a thin wrapper over the hg-git extension that lets me push my Bitbucket repos to GitHub for all my open source projects. I can then accept pull requests on both Bitbucket and GitHub, and merge and push back to both. As a Mercurial/GitHub fan managing projects with a decent amount of activity, it's fairly seamless.

Shiny! Have you considered writing some tests for that? Mercurial's testrunner and .t files makes it pretty easy.

I haven't, shame on me. I guess I thought it was such a small piece of code that it wasn't worth it.

Reply on news.ycombinator.com