It's, of course, impossible to do a practical experiment where someone doesn't learn, and therefore become biased toward, one of them first, and then learn the

It's, of course, impossible to do a practical experiment where someone doesn't learn, and therefore become biased toward, one of them first, and then learn the other after. For my part, what I can say is, I used Mercurial for one year, and Git almost exclusively (I do occasionally touch Subversion) for a straight decade after that. And I still find myself having to consult Git's documentation far more often than I ever did with Hg. And, even now, I find myself having to un-pick minor screw-ups in Git more often than I did after only a couple months on Mercurial. I'm pretty sure that the problem here is ultimately the UI and not the data model. No, I'm sure it is. Every time there's a conversation about Mercurial vs Git, and someone says, "Git's not that bad, all you have to do is learn the data model, and then learn all the different ad-hoc ways the UI is bound to it," my immediate thought is, "You see, that's exactly the point. The thing that's nice about Hg is that you don't have to take this extra learning step, because the data model and the UI model are one and the same." Also, merge conflicts seem much more common in Git. I'm not sure if that's a UI problem or a data model problem; I could see it being either or both. In any case, I felt much more comfortable allowing branches to live for days in Hg. In Git, branches that survive past 24 hours seem to always result in either shaving or getting trampled by yaks.