What are the best and must-have hg / mercurial extensions? [closed]

Question

I've been dabbling with hg / mercurial lately, namely in conjunction with Fogcreek's Kiln, and I'm trying to figure out what the must-have extensions are. Its a little tricky sifting through their extension list because I'm not interested in testing any buggy or impractical extensions, even if their description sounds awesome.

So, which hg extensions do you use?

See Using Extensions

Weekday

Probably NOT "deps" - my initial testing makes it seem too buggy/new to use – Weekday

To the list I'd also add task extension to manage "coding tasks" and prompt extension to show repository info on the shell prompt. Prompt can use the task extension. Them both are not shipped with hg. – Anette

Answer 1

My own hit list:

The simple ones you must have:

1. color: colorize output from commands like diff and status, which makes it easier to assess.
2. pager: browse long output a page at a time.
3. fetch: pull, update and merge from another repo in one step.
4. graphlog: display revision graphs in your shell, incredibly useful for looking at the branches in your log history.
5. hgk: browse the repository with a graphical interface (see also TortoiseHg and Murky)

If you enable pager, you should configure it to not interfere with certain commands:

[pager]
pager = LESS='FSRX' less
ignore = version, help, update, serve, record

The intermediate extensions I highly recommend (and use frequently):

1. record: lets you interactively select hunks of files to commit - perfect for when you are in the middle of one set of changes, and you end up fixing something that should have its own commit.
2. extdiff: configure an external diff tool (such as meld)
3. share: have multiple clones use the same repo history

The Advanced extensions I would not be without:

1. mq: manage a stack of patches. Very powerful, allows layering of patches on top of the tree.
2. notify: send email notifications when a repo is changed.
3. rebase: reapply local changes on top of a new parent revision.
4. largefiles: work with large binary files outside the hg store

All the above are bundled with Mercurial, and are stable and well-tested. I highly recommend all of them.

Non-core extensions worth investigating:

1. shelve: selectively put aside changes (at the granularity of hunks) and restore them.
2. acl: selectively allow access to different parts of the repository tree

Superseded extensions and migrated to core (info from @durin42):

• forest was been superseded by the subrepo support introduced in v1.3
• bookmarks is in core and always enabled
• transplant is superseded by graft, a core command
• histedit is in core as of v2.3, but is disabled by default
• inotify is not recommended, as there is apparently a bug due to a race condition

Firstfoot

Any other comments on Subrepo vs. Forest? I'm not positive that either of them are actually useful/usable - which might imply I'm just 'doing it wrong.' I'm particularly interested in a robust improvement to SVN's 'extern' – Weekday

color does not work on Windows (mercurial.selenic.com/bts/issue1579) – Incite

@JJBigThoughts: I have recently started to experiment with subrepo support, with a view to using it for a very large project. According to the Mercurial authors, subrepo support is still somewhat experimental. Currently it works much like svn:externals, but only a few commands know about subrepos. The basics seem to work well, AFAICT. The main difference is that the version of each subrepo is effectively pinned, as the parent stores a reference to its revision number as well as location (which isn't necessarily a bad thing). – Firstfoot

@Incite The colour extension seems to work fine in Cygwin. – Firstfoot

How about patchbomb? I find it very handy, at least when you do open source stuff and review happens via mailing list. – Cathcart

@tonfa: sure, patchbomb looks very useful; I just haven't tried it yet so I can't recommend or comment on it. On a related note, the extensions that Google developed for Go source reviews via Reitveld look very interesting. – Firstfoot

@Incite color extension in ANSI mode + tpager are working fine for me on Windows (tpager can be fount on Bitbucket and CodePlex) – Erde

color has been fixed in mercurial 1.6 – Incite

histedit is part of the latest hg release (2.3), bigfiles became largefiles and is also now part of the tree (since at least 2.2, but maybe earlier). I'd be a little wary of inotify - it sometimes has races that result in weird status output. transplant is superseded by the core 'graft' command (which is smarter). Starting in 2.1 (I think) bookmarks are always on. – Decosta

@Decosta I updated the answer based on comments here and in the recent HN article. Please let me know if there's anything I missed or needs updating. – Firstfoot

Create an awesome list with this inside! :) There's one for git. I don't use mercurial much, but looks like there's plenty of good things for mercurial too! – Camacho

These from your list are marked as deprecated: fetch, graphlog and record. Saw this using hg extensions help – Camacho

Answer 2

Not yet mentioned: mercurial_keyring

https://www.mercurial-scm.org/wiki/KeyringExtension

"Keyring extension uses services of the keyring library to securely save authentication passwords (HTTP/HTTPS and SMTP) using system specific password database (Gnome Keyring, KDE KWallet, OSXKeyChain, dedicated solutions for Win32 and command line)."

I use ssh to access my repos on GitHub and Bitbucket, and my keyphrase is held in the keychain. This extension lets Mercurial get it whenever needed.

Also required for me: hg-git

http://hg-git.github.com/

Mercurial plugin letting you pull and push git repos using hg as a client. Use it all the time.

Cumae

Answer 3

graphlog and mq are especially tasty.

1. Convert: convert to and from other systems
2. Mq (Mercurial Queues): deal with changes as a stack of patches
3. Forest: lets you commit to and update many nested Mercurial repositories at once
4. Share: to save time and disk space when working with similar repositories
5. Hgk: gives a graphical view of history
6. Graphlog: I always type 'hg glog' not 'hg log'. An ascii art view of history
7. Transplant: Useful when you only want to merge a few changesets from another branch. The newer hg rebase may have some overlap.
8. Rebase: A different way to deal with changes as a set of changesets on top of a branch. git users like to rebase. May replace mq for many use cases.
9. Shelve: A place to stash the working copy's changes if you have to work on something else for a while.
10. Bookmarks: Name the newest commit on a particular branch. Similar to git branches.

Wilbert

graphlog is now built-in and always enabled with -g for the log command (and incoming an outgoing IIRC). – Nonmetallic

Ry4an: "now" meaning in tip? Not in 1.4.1 AFAICT. – Coltson

The -g flag for log is to enable git style diffs, which is completely different from graphlog. – Cabbala

My error. It's -G to get a graphlog out of graph, but you still need the extension enabled for now. – Nonmetallic

you can also add progress extension – Verticillate

Answer 4

If you're working with a slowish host like Bitbucket, progress is essential. Otherwise hg push looks like it's hung :\

Cascabel

Answer 5

My list:

1. graphlog. I use it much more than hg log. (wish it could restrict to branches)

2. purge. remove all files not in Mercurial. I use this instead of or as a cleaner version of make clean.

Less used, but nice:

• children (lets you say "hg children -r XXX")
• parentrevspec: lets you say stuff like "foo~2 = foo^1^1 = foo^^ = first parent of first parent of foo"

I keep trying to use the history editing tools, but keep running into limitations. I want them to work.

• collapse
• histedit
• I consider rebase a history editing tol as well

By the way, beware: hgk and fetch are "unloved": https://www.mercurial-scm.org/wiki/UnlovedFeatures. But then, SubRepos are, not unloved, but a feature of last resort, and I use subrepos.

Persuasion