1. coherence of lexicon : the words used are not as intuitive as subversions and mercurial.
That's because you're used to them, and Subversion and Mercurial share a huge part of terminology. In Git there can't be a "git update", because you don't have a centralized server to update from. "update" means to fetch new commits, but since you always HAVE the repository on your harddrive, there's nothing to "update". Same goes with "git commit", where many people are confused because it doesn't "commit to the 'main' repository": It does what it says, commit your staged changes to YOUR repository. As soon as you've learned the fact, that you own a fully working and complete clone of the repository, things will get easier immediately.
That's not at all what I was meaning. Let me rephrase it : the natural (like in "not from by previous similar tool experience) way to express those concepts are not used in git. The wording is not well thought because it rely on the way git works internally but should have been thought to provide a "natural" (as much as we can) way to represent the ideas behind git, whatever the implementation.
Now, in Mercurial, update does not mean the same than in SVN, like for git. I'm not pointing a specific word and comparing to SVN, I'm saying that , as others have observed, the wording isn't as natural with git than in mercurial and bazaar. Even if both don't have the same semantic mapping than for Subversion.
But lets say it's a minor problem (even if it has cost).
2. lack of feedback on errors : that can be a problem for "we don't have time for this shit" business - but that's ok for those who passed enough time studiying git to understand their errors easily
That counts for every software, not only SCM. If there's an error you don't understand directly, you have to look it up. Happened many times before with me and Subversion due to strange behaviour (lockups, cleanups, the list is long).
No. That might be the norm on basic linux tools, yes, but it's not the norm at all. Most tools I use does report clear errors when something failed in a process. They don't "report nothing" and let you have to look for what happened. Not everyone have the time to understand those kind of things.
What's really dangerous is that if there is no error report, then sometimes you could do something wrong and not know it. That's really a problem.
Mercurial does report through the python-exception system, so most of the time the errors are full of informations that even if you don't understand them you can ask online easily by providing the error report.
It's common knowledge that following some public principles with git does avoid you almost any problem, so let's say it's not a real problem.
3. complex manipulations are too complex : most of the problems with git arise when you use more than the 4 basic commands.
I understand what you mean, but I think things get easier once you dive deeper. I love to compare this with Vim: When you start, you don't have to know the full commandset, only the basics to get you started. As times passes by, you may have the feeling of "Can't this be done more effectively?", then you fire up the docs and check if there's anything you can do better.
Same goes with Git: You will probably do a lot of "revert stuff" manually in the beginning, or wild copying between your working copies. Later you get used to cherry-picking, rebasing, commit rework etc.
I agree. Still, learning have a cost. The problem arise in almost all business or even spare time : do I really need to spend lot of time on understanding this tool to make it useful? Git is expensive compared to Mercurial to learn, but both are more expensive than SVN.
So it's more a cost concern, as with any tool choice.
4. Windows port has often been a problem (not sure it is still) because far from being stable.
I can't tell you MUCH about this, however the times I've used Git on Windows it worked perfectly and didn't have any noticable problems (I used the CLI version aswell as TortoiseGit). But since I'm mainly on Linux, there're probably others who know this better.
You might have more informations about the windows case by reading the blog posts I pointed. I'm not a big user of Git, I use it mostly to clone repositories, so I know basic usage don't expose those problems.
1. you're working with people that are familiar with git, so you choose git, or with mercurial so you choose it, etc.
You forget the part that says "The team has used SCM A, but after testing out B, they switched to SCM B." 
That happen, but not oftenat all. In our current case, I'm not sure that a lot of people understand the differences between Git and Mercurial, other than the alien-lexicon aspect. So, I guess that most of the time, a team will use one of those and not bother with others for years (like here with Git). That's fine as at least we don't have a clear killer-feater difference that makes one the obvious leader.
There are differencies between git and mercurial that make them unperfect choice BOTH.
That's true, absolutely. Most SCM have their raison d'être. I wouldn't use Git on data that's huge and binary (like drawings), for example. But when talking about DSCM like Git, Mercurial and Bazaar, then my choice is made.
No problem, we're not talking about personal choice here. It's more about what road did we gone through to get to this point. I'm looking for feedback, not flamewar
By the way, Mercurial have the BigFiles extension that might become standard. One of the power of Mercurial is that it's really easy to extend. But it's less a toolbox than Git.
Whatever you choose, understand that the cost of understanding git can be costly for some business.
Using something different or new always means that it costs time and breaks the "normal work" of a "business". The question is: Is that time well spent? For example, you only need 2 weeks to master Subversion, but 6 weeks to master Git. But if you're so much more productive with the latter, why shouldn't you invest the time? (replace Subversion and/or Git with anything, just an example)
Yes, I agree fully, as said before. Now, a lot of people say that Mercurial and Bazaar are lest costly than Git on time spent, but the difference are minor enough to make Git a good choice anyway. For me the real problem is that it's hard to tell for each project wich one will work better. So in the end, you might even use a dice to choose between Git and Mercurial... even if being on Windows might be big hint
Anyway, choosing git or mercurial or any other is good, as far as it's decentralized. It really helps "lockfree" parallel work
Definitely, yep. I want the power of an SCM without messing around on an upstream repository. ;-)
I'd like to use Git in a future project, after having use Mercurial a lot with my current ones. I think I'll get more points of coparison from that.
I wish GitHub would provide native Mercurial support... that would be the dream
Maybe it's time for some people with a huge amount of time to create something universal you can switch to and from.
I've made some research and event answered (successfully) about that on stackexchange. There is not current solution that match my personnal requirements.
But I guess some people are working on it
