I don't think user-friendliness should be a primary goal for a version control system. The reason being that this is something we use day in and day out for years, so the importance of the learning curve is dwarfed by the power of the UI and the workflows it enables.
When I switched from svn to git (and don't take this to mean I'm comparing svn to hg, because obviously hg is in git's league, not svn's), the learning curve was steep, but after 3 months of daily use I understood git's internals and what the various commands actually do infinitely better than I did after 5 years of using svn.
In other words, I think git has an internal logic that allows it to fit into a small space in your brain once fully grokked.
As to the rebase vs merge debate, I've already written about this (http://darwinweb.net/articles/the-case-for-git-rebase), but fundamentally my argument boils down to this: Having a linear history allows me to resolve historical bugs better than a history full of merge commits. If I run a bisect on a linear history I will always narrow down a bug to a single commit instead of potentially a merge commit with hundreds of commits behind it. Now, merge commits give you more information about the history, but when topic branches proliferate that information becomes very hard to make sense of anyway. With rebased commits I can still see when they were committed, so it's not as if there is no evidence of the actual development. Being able to see the exact state a particular commit was developed in is useful, but in my experience does not offset the hassle of a very messy history in solving bugs in the current state of the code base.
I do think that user-friendliness must be a primary goal for a VCS, because I have to get people who aren't hardcore, balls-to-the-wall programmers to use it if I need to store their data in my tree. Hg can be picked up by those folks in short order and requires no "grokking" beyond what you can read on Spolsky's HG Init in half an hour minutes. (I have in the past worked with designers who were wholly out of their element with anything beyond HTML, CSS, and very simple jQuery-backed JavaScript; expecting them to "grok" their VCS was more of a demand than I wanted to make because I'd have had to teach them.) And, to be honest, I think having to "grok" your VCS is only slightly less ridiculous of a requirement for software to force upon its user than is having to "grok" your text editor. Similarly, is why I don't use vim and do use Sublime Text.
I don't think git's internal logic is more meaningfully flexible than hg's, but, IMO, hg provides a vastly more user-friendly experience. I could be wrong on this, but assuming I'm not--if you can get both, why not get both? =)
(And don't get me wrong--I realize the arguments for rebase as opposed to merge. I reject them for my own projects for reasons that are largely subjective, and prefer a system where they are difficult and not commonplace. It's totally a matter of taste, but one I do feel somewhat strongly about and is what I'm referring to by disagreements in philosophy.)
On text editors -- picking up Emacs was one of the hardest thing I ever did, as I had to learn new shortcuts, I had to learn to rely on the keyboard-only and I also had to learn some ELisp just to be able to configure it.
Because Emacs has some problems (it is hard to create new syntax-highlighting definitions, plugins break all the time, ELPA for package management is useless), I did try both Textmate and Sublime Text 2, several times.
But I keep going back to Emacs and personally I don't get how people can stand a text editor that doesn't even have proper UNDO (Textmate) or a text editor that doesn't have a workflow that is totally mouse-free. Emacs is also wonderful because it grows with you. Some things that should be simple are too hard indeed, but at least you can fix that.
Basically me switching to Emacs was similar to when I learned to touch-type. I did suffer, but productivity was increased tenfold in the end.
IMHO, you're not a user to require UI friendliness. The difference between a developer and a user is that users are using these applications casually. But if your day job is depending on a text editor, you should use the text editor that stays the least in your way, and friendliness has nothing to do with it. Ditto for version control.
On a side-note, race-car drivers in general do not use automatic transmissions. That's because they can change gears more efficiently than a computer can and because they don't need to eat sandwiches while driving.
I am comfortable in Emacs and quite good with vim. Both do get in my way, which is why I moved to Sublime Text for text editing.
I don't live in my text editor. I spend most of my time in IntelliJ or Visual Studio. The conventions of normal text editors are largely established, and so something that runs counter to those normal conventions--an emacs or a vim--do get in my way. It is a mental gearshift to go "oh, I need to do something different now", which is a drain on my concentration and a way to get annoyed and off track because I tried to go Ctrl-A in Visual Studio and it didn't do what I wanted it to do. The productivity benefit of not having to make my brain go modal or instantly remap my mental keybindings to use emacs even outweighed losing the extensions I liked (vimwiki has been largely replaced by Evernote for me now).
And, yes, VS or IntelliJ are more important than my text editor. They win by default--"Well, use vim/emacs for everything!" is unacceptable for reasons that should be obvious. Vim and emacs are nonstandard at their own peril, and conforming to them is a worse use of my time than using something that conforms to expectations.
That you don't "get" how I can stand it is OK; the important thing is that I can.
I spend most of my time in IntelliJ or Visual Studio.
It's understandable then why you don't like Vim/Emacs. Yes, working with IntelliJ/Eclipse/Visual Studio is painful for me too.
True anecdote - whenever I'm working with Eclipse, I have a shortcut that opens the current file in Emacs for me.
Vim and emacs are nonstandard at their own peril
I spend my time with Unix-related tools mostly, and Emacs/Vim shortcuts are not as nonstandard as you think. The Bash shell for instance uses Emacs shortcuts. In fact, all shells (like irb or ipython) powered by Readline also use Emacs shortcuts.
That you don't "get" how I can stand it is OK;
the important thing is that I can.
Don't take it as a criticism on yourself; I said that mostly because I'm pretty annoyed with Textmate - it does some things really well but other (IMHO important) features are totally retarded.
The analogy to text editors is bad though, since everyone can choose the UI they like for text editing, whereas for source control the choice of UIs is much reduced.
In other words, I can choose Vim/Emacs, slog away and get proficient, and someone else can read my code with notepad. With VCS, I'm asking casual and hardcore users to use the same UI, so it better appeal to both.
Yeah, I don't have those people in any meaningful capacity. If I did then hg would immediately be a strong contender.
With regards to the philosophical difference, I see where you're coming from. This is the reason I use OS X instead of Linux for instance, it's more important for me to have a simple and usable GUI than to have ultimate control and flexibility. With text editors and version control systems I don't feel that way though. As a matter of fact, I do use vim, and I don't think it's ridiculous in the least to use tools that require "grokking" for one's core competency. I'm not saying everyone should use these tools, but I do believe in my heart that the power of vim can not be equalled by a more user-friendly text editor. Sure you can have a more powerful IDE for language X or Y, but I doubt any of those will be able to stick around and grow with me over the dozens of languages I will use over the course of my career. Since I plan to use these tools for decades (unlike programming languages themselves), the importance of newbie-friendliness approaches zero. That's not to say the UI doesn't matter, but just that the factors that matter are the ones that are applicable to the master rather than the apprentice.
I never said "newbie-friendliness," though I can see how that might have been implied by my last post. I said "user-friendliness", which I think also lends itself to easier uptake from novices. Sorry for the confusion.
I know vim quite well. I still consider it onerous and unpleasant to use, and I find claims of its "power" to be overstated; I have noted before and still think to be true that editing text isn't the hard part of my job. I am definitely suspicious of claims that "it'll still be there in ten years" to be hugely important; my editor might change in ten years, but Cmd-X will still be cut and Cmd-V will still be paste, you know what I mean? The specifics of exactly what text editor I use matter so much less to me than "does it not make me hate using it?".
All of that is an aside, however, and tangential to what I was saying: for me, the visceral reaction to both vim and git is not a pleasant one; I find them to be designed for people whose mental model with regards to computer interaction is alien to mine, and despite being capable with both I find such tools uncomfortable to use. I don't consider either user-friendly (and, I think, to most people), and while I don't begrudge those who prefer those tools, life is simply too short to spend my time squeezing blood out of that particular stone.
When I switched from svn to git (and don't take this to mean I'm comparing svn to hg, because obviously hg is in git's league, not svn's), the learning curve was steep, but after 3 months of daily use I understood git's internals and what the various commands actually do infinitely better than I did after 5 years of using svn.
In other words, I think git has an internal logic that allows it to fit into a small space in your brain once fully grokked.
As to the rebase vs merge debate, I've already written about this (http://darwinweb.net/articles/the-case-for-git-rebase), but fundamentally my argument boils down to this: Having a linear history allows me to resolve historical bugs better than a history full of merge commits. If I run a bisect on a linear history I will always narrow down a bug to a single commit instead of potentially a merge commit with hundreds of commits behind it. Now, merge commits give you more information about the history, but when topic branches proliferate that information becomes very hard to make sense of anyway. With rebased commits I can still see when they were committed, so it's not as if there is no evidence of the actual development. Being able to see the exact state a particular commit was developed in is useful, but in my experience does not offset the hassle of a very messy history in solving bugs in the current state of the code base.