Design horror: same command, different meanings

As I already had the chance to write in a previous post, I really appreciate distributed version control systems; I consistently use them at work and for many of my side projects. I typically switch between git and mercurial repositories, with the former being my primary choice lately, and there is one specific command that always troubles me when I do that: pull.

There is one wonderful piece of inconsistency between the two systems, one that often leads to confusion for new adopters and unnecessary hassle for experienced users. If you are familiar with both systems, you may already be thinking about the culprits. If you are not, you may be more careful about the pull and fetch commands after reading this post.

Here is what the Git Reference says about fetch and pull:

git fetch download new branches and data from a remote repository
git pull fetch from a remote repo and try to merge into the current branch

And here is mercurial‘s documentation about pull:

A pull propagates changesets from a “remote” repository (the source) into a local repository (the destination). It can optionally update the working directory (specify option -u or –update).

See what we have now? A fetch on Git acts like a pull on Mercurial, and a git pull does a bit more than a hg pull.

Git and Mercurial were designed in parallel in the same period by different groups, so this inconsistency can partially be explained by their history and context. What troubles me, however, is that mercurial comes with an extension that can enable fetch. Guess what it does?

This extension is a convenience wrapper. In the simplest case, hg fetch acts like hg pull -u — it pulls changes from a remote repository into a local one and updates the working directory. (This is like the “update” command as found in Subversion or CVS.)

As if we needed more ambiguity, we now have in Mercurial a fetch command that does quite the same thing Git’s pull does.

Inconsistencies like this one are frequent in software development: they are a sign that we should pay more attention to what products and tools similar to ours are doing. This does not mean we should shamelessly copy what other people are doing or stop innovating just to ensure uniformity, but we should still strive for consistency across similar applications if that means less confusion for our users.


Published by

Alessandro Bahgat

Master geek, developer, avid reader and one of the minds behind and

3 thoughts on “Design horror: same command, different meanings”

  1. Just curious (because Open MPI is in the slow spocers of migrating from SVN to Mercurial): is your favoring of git because you long-ago made the mental leap from centralized VCS’s to DVCS’s, and therefore the mental delta (no pun intended) from Mercurial -> Git was fairly small?I have always thought of svn, hg, and git as somewhat of a linear spectrum: svn at one end, hg in the middle, and git at the other end. hg and git are both DVCS’s and fairly feature-comparable, but hg’s commands are much closer to svn’s, making it easier for cvs/svn dinosaurs (like me) to switch to hg (compared to switching to git).I use git about once every 6 months (typically interacting with someone else’s project) and it always confuses the heck outta me. The next time I use it is just long enough later that I forgot everything I learned the previous time. Plus, 95% of my day is still comprised of working with SVN (read: a non-DVCS), so all the concepts are not kept fresh in my head. So I have mental models in my head that git is extraordinarily complicated and difficult to learn, and that Mercurial although it’s a DVCS is much closer to the stuff that I currently use every day, and therefore is much easier for me to learn and migrate to.So my question to you is: do you think your experience / bias / whatever is that it’s a natural evolution from CVS -> SVN -> Mercurial -> Git? (vs., for example CVS -> SVN -> git)Also, what motivated you to look (again) at VCS’s and move to a new one? Is Mercurial somehow deficient for your requirements / needs? You mentioned that git seems a little easier to make new projects do you do that often such that it’s worth the mental delta to learn a new system (and genuinely be *more* productive)? And/or even since the mental leap from SVN -> Mercurial is clearly long-since overcome and there’s nothing new you need to learn to do what you need to do with Mercurial, what makes git better such that it makes the git mental bootstrapping worth it?(keeping in mind that all of these questions may be attributed to the fact that I have a [potentially inaccurate] complex model of git in my head, as described above)Thanks!

  2. I started using mercurial because I needed a VCS that allowed me to browse my project history even when I was offline.
    Initially, I used it for my own projects, where I was the only (or the main) person working on the codebase. During that phase, the migration from SVN was quite effortless.
    When I started using it for my work project with smallish teams, the major pain point was the inability to update single files on a dirty working copy, but everyone picked up the new model quite easily, after a brief explanation of the underlying philosophy.

    Concerning git vs mercurial, they are very similar and, often, almost equivalent. Git is a bit more powerful out of the box (consider rebase), but you can add lots of features to mercurial via extensions. Of course, the extra power can be harmful if you don’t know what you are doing. 🙂

    In my experience, the real leap happened when switching from traditional VCS to a distributed system, but the benefits are so many that I would never go back. Switching from hg to git (or vice versa) is eventually a matter of habit. I moved to git mostly because there are better tools for it (GUIs, extensions) and it is supported by many editors/online services (e.g. Heroku).

What do you think? Leave a Reply:

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s