Like everyone else, I'm now a git user, but I still say that Mercurial was the most elegant of the bunch, at least in terms of its emmiently predictable and well-designed CLI, even if the software itself gave up the ghost years ago.
Back in the day, when version control systems were still duking it out, I used to try and defend mercurial to rabid git fans, mostly to no avail. I always felt that I was at a bit of disadvantage in those conversationa (cue the git fans yelling "Yeah, cuz mercurial SUCKS!"), because I was always willing to concede, despite appreciating mercurial's virtues, that git actually did have its strengths as well as its weaknesses, while the git fans were rarely so magnanimous with any other VCS.
It has to be said: git is blazing fast, with a very flexible branching model and large mindshare. The branching model and the existence of things like github are probably, in fact, the principal strengths of git, and the principal weaknesses of mercurial. It's a good thing too, because as far as the CLI is concerned, git is simply garbage.
The fact that there exists a site like the git man page genertaor should tell you something about git's CLI.
git branch to list and create branches, but you use
checkout to switch to a branch, unless it's a new branch, in which case
it can also be used to also create the branch if you supply it with the -b
So far this isn't actually that bad. The
checkout command is your
moving around command - you can use it to switch to an arbitrary commit, for
example. The branch command is your branch management command. The -b
option to the checkout command does add a certain wart to the whole thing -
it would be more intuitive, in my opinion, if the branch command created
and switched you to the branch automatically - but so far it's nothing
horrible, even if the term "checkout" here seems a bit more general than one
might be used to.
Ah! But you also use
git checkout when you want to revert a file,
i.e. undo the local changes you just made to it. I understand the
underlying conceptual link between the two use cases, but it's not the
normal way I usually think about these operations. There is, in fact, a
git revert comand but, surprisingly, it doesn't actually work on files -
it's used to create commits which undo (revert) other commits. Of course,
if you want to just revert all the local changes in your repo, you can do so
git reset command, which comes in hard and soft flavours, like
ice cream, and which also doesn't work on individual files, but which
provides a plethora of options, mostly revolving around whether your changes
are staged or not.
Oh yeah! Git also provides a staging area, which I've personally found of limited value, especially when you consider how easy it is to amend commits. But your mileage may vary on that front.
And don't even get me started on
git rebase, the swiss amry chainsaw of
history editing commands, which appears to be specially designed to mess up
Don't misunderstand me. I use git every day - sometimes even effectively! - and I would never use mercurial on a new project. It's just that I sometimes think that there are git fams who use it because of its difficulties, rather than in spite of them - possibly the same kind of people who enjoy competing in Obfuscated C contests. They are a flavour of nerd to which I don't really relate.