Jordi Gutiérrez Hermoso

D has been a real pleasure for me. I did the 2017 AoC in it: http://jordi.inversethought.com/blog/advent-of-d/ The richness and flexibility of compile-time features almost make it feel like a lisp, with the slight downgrade of sometimes working on strings of source code instead of sexps. Regardless, like the article says, D's metaprogramming alone is worth the entry price of reading a few books or tutorials about the language.

Agreed, revsets are another amazingly useful feature. Also check out templates[1], which let you customize pretty much everything about hg's output. [1] http://jordi.inversethought.com/blog/customising-mercurial-like-a-pro/

Best tool for the job, can't agree more with that. We have a team that insists on using git when: - it is just a small team (less than 5 devs) - there is no github, just a locally hosted gitorious instance (proprietary project) - the lead dev who picks git is using Windows half the time - there are less technical people who need commit rights (e.g. changing reports layout, changing CSS, etc) I believe the "git already won" mentality (which is very apparent in the comments of both OP article and HN) get these people to pick git over mercurial. And once they become familiar with git, they won't let go, due to the sunk cost of learning gitology[1]. [1] http://jordi.inversethought.com/blog/on-gitology/

To the author - I'm in the opposite boat where I've used mercurial for nearly 10 years but any time I try to use git I get lost. Everything in your post rung out to me as why I rather enjoy and understand hg (with exception to absorb which I haven't yet tried). I highly recommend checking out this blog which discusses adding a command which is a customized log. It's made getting a visible understanding of my working state & phases tremendously easy. http://jordi.inversethought.com/blog/customising-mercurial-like-a-pro/ Additionally if you're planning to use evolve, most of the instructions I've seen for using it indicate installing it via pip, however I've only run into issues with that (as well as coworkers and others). Instead I recommend cloning the evolve repository and pointing the extension location to it (seen in .hgrc gist below). Upgrading is as simple as going into the evolve repo and running `hg up`. I can't wait until it's shipped with mercurial. The evolve repo can be cloned from: https://www.mercurial-scm.org/repo/evolve This is from my .hgrc (for a mac) which customized the wip colors a bit more (and fixes a recent issue where one of the original revset commands used by the blog has been deprecated/removed). https://gist.github.com/neandrake/e770ea7b3d6bf8299f6be2ca0800290c

> Git is intuitive with a small number of concepts necessarry to grasp my whole workflow. http://jordi.inversethought.com/blog/on-gitology/ explains git's complexity extremely well (without even getting into horribleness of the command line UI). The following is a key quote, though you should read the whole thing. The following gitological concepts are not particular to git: * repositories (repos) * commits or changesets (csets) * directed acyclic graph (DAG) * branches * pushing and pulling changes * whole-repo tracking, not individual files * rebasing csets * pushing and pulling csets The following are purely gitological and add unnecessary complexity, in addition to eventually being unavoidable: * Exposing the index/staging area * Exposing other implementation details: blobs, trees, commits, refs * refs and refspecs * Branches are refs * Detached HEADs (a.k.a “not on a branch”) * Distinguishing remote and local tracking branches * Choosing which branch to pull onto * Bare repos * Hard, soft, mixed resets * Porcelain vs plumbing

I am used to working in large repos (>100 commits/day), which generally means that something like 'git log --graph' contains a lot of extraneous information. The most common workflow I have is that I've got a couple of old working branches (like featurea and featureb), and I want to see if I need to update featureb to a newer head or not, or if featureb was based on featurea or featurea-v2. A demonstration of this kind of thing is 'hg wip' here: http://jordi.inversethought.com/blog/customising-mercurial-like-a-pro/… Another thing I would use revsets for is answering queries like "which of these changes that's on the public repository made its way into the internal repository (which periodically merges from the public repo)?"

Same here. I used to regard http://jordi.inversethought.com/blog/i-hate-git/ as my hero, and then I had to start using git in a new gig, and never touched mercurial since. If the goal of using a vcs is to have meaningful atomic commits, nothing beats git staging area and interactive rebase.

Even GNU's philosophy has a few puzzle pieces missing from the box. - JordiGH's "Exercising software freedom on Firefox" <http://jordi.inversethought.com/blog/exercising-software-freedom-on-fi… Jordi spends a lot of time dealing with the infuriating reality of what it takes to build Firefox. The punchline (not stated in the post) is that Firefox uses an Emacs-like architecture, so basically none of these frustrations or the time wasted on them were actually necessary; the code Jordi wanted to twiddle require no/little actual building. The Firefox team (particularily given how well-funded they are) could enable a contribution path where making an improvement to Firefox is about as easy as opening up an elisp file and making the requisite tweaks, but they don't. Related, and I've mentioned this before—the Zotero app is built on XULRunner/Gecko, but XULRunner was killed by the big brained folks who had the power to do so in an attempt to free up resources for their totally successful designs for the future. Rather than throwing Zotero contributors under the bus and into a potential quagmire of dealing with C++ and Rust compiler output that they don't care about on failed builds, and costing them hours for successful builds (if a successful build is even possible for that contributor's hardware), the Zotero build scripts instead download Firefox and then repack it, et voilà—when you open it you're running Zotero. (Side note: former Mozillian here, and there's no…

> Question: How does Mercurial deal with garbage collection? After all, the desire for garbage collection is by far not unique to Git -- any version control system that has the equivalent of `commit --amend` and rebase should provide it. Garbage collecion is an issue that is 100% unique to Git. No other VCS even thinks about throwing user data in the repository away without the user explicitly telling it to. Once you have a user telling you to throw the data away, it can do that. There is no need for GC; this is purely an artifact of Git's implementation. I'm honestly not sure why you think you'd even need a GC for `hg commit --amend` or `hg rebase` (or similar operations in other VCSes). > As for not needing the extension, it seems to me that having "dangling" commits would be very difficult to use without some decent visualization of the dangling commits, such as what the blog post shows with `hg show`. I'm not sure where you get the idea. This feature is, after all, not unique to Mercurial. It's Git that has the oddball semantics that no other VCS on earth has. Mercurial has been able to graphically show the graph for ages and the ability to just list open heads, too (`hg heads`). If you look at the code, the implementation of the show command is largely just a templated graphlog of a particular revset. For example, `hg wip` [1] (for "work in progress") has been doing something similar just using revsets and templates from core Mercurial. > The point of the purely…