undefined | Better HN

0 pointsstevelosh15y ago0 comments

I'm not the OP, but I'll give my reasoning for preferring Mercurial: its CLI has commands that each do one thing instead of commands that have options to do anything.

For example: `git checkout` can change the contents of files without changing where you are in the DAG, change where you are in the DAG, and even create a new branch. In Mercurial you'd use three separate commands for these things: `hg revert`, `hg update`, and `hg branch`.

The problem with git's approach is this: making every command very flexible through options means that you need to document the interaction of all these options in the man pages. That makes the documentation for each command harder to read, especially when you're in the middle of trying to get something done with a project and just want to do something quickly.

For a real example, look at the help for the two SCMs' commands for changing the contents of a file:

    $ (hg help revert) | wc -l
          47
    $ (git help checkout) | wc -l
         276

Some might say: "But `git checkout` can do so much more than `hg revert`!" That's absolutely true. However, every time I want to look up how to revert file contents I need to wade through hundreds of irrelevant lines in git's documentation. When I'm using Mercurial I say "Well, I know I need to use `hg revert`, let's just look at those 47 lines of help and find out what exactly I need."

When you combine the help for the equivalent Mercurial commands it's still more succinct than git's help, because splitting individual actions into different commands means you don't have to document interactions between options:

    $ (hg help revert; hg help update; hg help branch) | wc -l
         113
    $ (git help checkout) | wc -l
         276

TL;DR version: Git's decision to make its CLI's commands very flexible results in painful documentation, so I perfer Mercurial.

0 comments

7 comments · 3 top-level

snprbob8615y ago· 2 in thread

I learned Mercurial first and found the vast majority of its commands to be highly intuitive for the 4 core actions of a distributed version control system

1) Check-pointing code 2) Jumping back (or sideways) in time 3) Sending code to others 4) Receiving code from others

However, once I really understood the distributed version control model, I found myself thinking in terms of the DAG and wanting more control over it. I started viewing my version control system as a tool for more than just version control. I started viewing it as a tool for understanding and communicating about my code. I started using it as a tool to manipulate my code.

Then, for one small project, I tried Git. It drove me NUTS for about a week. I was going to smash things. I was so angry about it using stupid cryptic terms for simple things. I was annoyed by the complexity of overloaded, highly flexible commands. But once I translated the vocabulary, the commands stopped seeming so complex. Instead, they seemed like a reasonable abstractions. Each of the sub-operations they can perform are really just specializations of one kind of operation. It became second nature. I started doing swiss-army-knife voodoo with Git that Mercurial could only accomplish with a giant pile of half-baked plugins, blood, sweat, and tears.

Now, I only use Git.

tldr: Git is a more abstract, more powerful tool than any mere version control system. This is only something you come to appreciate with experience.

lars51215y ago

Can you provide a concrete example of DAG editing which you had trouble doing with Mercurial?

snprbob8615y ago

From things as simple as "git stash" to anything you'd use Mercurial's MQ extension for and beyond. Also, the Index, a concept which I initially wrote off as a frustrating extra step, turns out to be super useful for moving around chunks of code quickly.

cageface15y ago· 2 in thread

TL;DR version: Git's decision to make its CLI's commands very flexible results in painful documentation, so I perfer Mercurial.

I guess that jibes with my own experience. I've learned how to use git not so much from intuition but memorization of what all the commands do and how they interact.

Github seems like a real juggernaut now though. So many job postings now specifically ask for github urls, although I suppose a bitbucket link would probably be ok.

masklinn15y ago

> I've learned how to use git not so much from intuition but memorization of what all the commands do and how they interact.

Yeah that's what grates me about Git: apparently, unless you're willing to learn all of it from the implementation details up (which I am not as I have absolutely no interest in implementing my own DVCS) you will forever be limited to rote-learned "recipes" because the command-line interface makes no sense in and of itself, it only makes sense if you understand how it relates to Git's implementation details.

I'm sure somebody will chime in with "well make your own CLI then" or "other people have built new porcelains and they have not taken off". Of course that won't work, for two reasons:

1. To build my own porcelain, I'd have to learn all of Git's implementation details. See above

2. People who build their own porcelains have to do it as well, and by the time they're done learning... they don't need a separate porcelain anymore. They might not even realize why they were trying to do it in the first place. And so they leave their project in a mostly-broken state and go on with their life, and the next guy comes around and builds his own from scratch.

noidi15y ago

>> I've learned how to use git not so much from intuition but memorization of what all the commands do and how they interact.

>Yeah that's what grates me about Git: apparently, unless you're willing to learn all of it from the implementation details up (which I am not as I have absolutely no interest in implementing my own DVCS) you will forever be limited to rote-learned "recipes" because the command-line interface makes no sense in and of itself, it only makes sense if you understand how it relates to Git's implementation details.

That's what I thought, too. After I had typed in one meaningless magic incantation too many, I bit the bullet and dug into the source to understand _why_ the same command was used for three completely unrelated goals (I can't remember what the actual command was, probably reset or checkout).

To my dismay the goals were completely unrelated even in the source code. The command parsed its command line and took different code paths -- not even working on the same data structures -- depending on its arguments.

It's of course possible that I didn't read the code well enough, but even at the source code level it is not always _obvious_ why Git's commands have multiple roles, and why different commands can be used to reach the same goal. My first thought was that at some point it just must have been slightly easier to add a new switch to an existing command than to add a new command.

Needless to say, I'm now a happy user of Mercurial (and its wonderful pbranch extension, among others). My mental model of Mercurial's workings might not be completely accurate, but so far it's been consistent enough to never surprise me, and the commands that I use make intuitive sense within that model.

steveloshOP15y ago

To cageface (I can't seem to reply to your comment for some reason):

An alternative solution is to use BitBucket and mirror everything to GitHub: http://hgtip.com/tips/advanced/2009-11-09-create-a-git-mirro...

j / k navigate · click thread line to collapse