Hacker News Reader

Comment by millimeterman | Hacker News Reader

I think the best argument against git is to use mercurial for a few months. It has exactly the same functionality but a nicer and more streamlined interface, especially when it comes to branch management.

View on HN

I think this point can be concisely summarized with:

  $ git help commit | wc -l
  506

  $ hg help commit | wc -l
  59

  $ hg help commit -v | wc -l
  96

Also, git currently has 169 subcommands by default, vs. mercurial's 50 (more available as extensions though).

Yeah, when dvcs started becoming all the rage I tried mercurial first for some toy projects and really liked it. When I finally had to start using git I was absolutely baffled that it had won. I feel like git needs something that sits on top and does most the normal configuration and wraps the api. It reminds me of the problem with emacs, there is so much it’s just overwhelming to people.

Technically this already exists; git commands are divided into two groups, plumbing and porcelain. Plumbing commands have stable interfaces and are intended for building alternative interfaces with; porcelain commands are intended to sit on top and be the actual user interface. They're what you're used to using.

I love mercurial but since I've gotten used to git I miss the lack of the staging area and stash in mercurial. I have to grudgingly admit they're very useful.

In some cases (all my usecases, but perhaps yours are different) the staging area can be replaced by some combination of "hg commit --amend" and "hg commit --interactive" - or in older versions "hg rollback" and "hg record".

You can get the "git stash" with the shelve extension: https://www.mercurial-scm.org/wiki/ShelveExtension

Do you think mercurial has a better data model, or could git reach parity with just a better interface?

I don't know anything about mercurial's internal data model, so it's hard to say. In particular, it makes some fundamentally different choices (e.g. no staging area, the ability to use unnamed branches). I certainly think git could do a lot better with its interface though.

Reply on news.ycombinator.com