

What are the Best hg/Mercurial Extensions? - pooriaazimi
http://stackoverflow.com/questions/1869040/what-are-the-best-and-must-have-hg-mercurial-extensions

======
snprbob86
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

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

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

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

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

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

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

