> 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.

>> 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.