No specific commands really, but I think the whole hg UI is just more consistent. I use both, yet with git I have to revert to `man` almost every day :/
Compare: `git branch xxx / git branch -a`, `git tag xxx / git tag -l`, `git show-ref --heads`
To: `hg branch xxx / hg branches`, `hg tag xxx / hg tags`, `hg heads`
There are also "duplicates" that I'm not sure why aren't folded into one command: `show-branch/branch`, `show xxx` which is `diff -c xxx` in many other systems, etc.
These are just simple cases, but there's loads of situations where you have to find out yet another command in git / yet another parameter to do what you want. Hg has better defined defaults and the whole list of commands looks like it was designed, while git looks like everyone just added what they needed... Auto-expanding commands in hg is also nice - I hate it when git tells me 'ci' or other short name is not a command (yeah, I know about aliases).
In some situations I also think that git does exactly what it's programmed to do... which isn't always the same as - what workflow makes sense in a specific case. For example `branch` creates a branch, but you still need to do `checkout` (or just `checkout -b ...`). Why? What's the common use case for creating a branch you're not going to work on? Which behaviour do you expect more often?
All in all, not the end of the world, but when you use the tool every day, it becomes annoying, especially if you see it can be done better.
There have been times that I've created a branch just to have a stopping point to which I can go back, but I wasn't going to do any work on it, at least not yet, like two choices on how to re-factor something, try one, if it fails try the other, but keep both around for testing.
There is a subtle difference. git-show is meant to show an object. A commit is an object, but so are other things. A more descriptive name would be 'git show-object.'
An example that I just came across in normal usage:
git show <branch_name>:<filename>
This will show you the contents of <filename> on <branch_name>. It does not show you the diff of that file for the latest commit to <branch_name>; it spits out the state of that file to the $PAGER. This is something that 'git diff' does not do. Note that <filename> doesn't even have to exist on the current branch, and you don't even have to have a working tree (i.e. you can do this in a bare repo to inspect file contents without actually needing to checkout a working copy of all of the code).
Compare: `git branch xxx / git branch -a`, `git tag xxx / git tag -l`, `git show-ref --heads`
To: `hg branch xxx / hg branches`, `hg tag xxx / hg tags`, `hg heads`
There are also "duplicates" that I'm not sure why aren't folded into one command: `show-branch/branch`, `show xxx` which is `diff -c xxx` in many other systems, etc.
These are just simple cases, but there's loads of situations where you have to find out yet another command in git / yet another parameter to do what you want. Hg has better defined defaults and the whole list of commands looks like it was designed, while git looks like everyone just added what they needed... Auto-expanding commands in hg is also nice - I hate it when git tells me 'ci' or other short name is not a command (yeah, I know about aliases).
In some situations I also think that git does exactly what it's programmed to do... which isn't always the same as - what workflow makes sense in a specific case. For example `branch` creates a branch, but you still need to do `checkout` (or just `checkout -b ...`). Why? What's the common use case for creating a branch you're not going to work on? Which behaviour do you expect more often?
All in all, not the end of the world, but when you use the tool every day, it becomes annoying, especially if you see it can be done better.