The usual scenario is that you do a pull before you push up your changes. But it might be the case that the current ancestor of your commits is the same since you pulled the last time (i.e. all the others haven't pushed anything yet), which means no merge is required and you can just push your changes without needing to pull.
Once someone else has pushed their changes in between, then you always have to pull their changes into yours (this is where git creates what is called a merge commit, which is a commit that hasn't been created the usual way with git add, git commit etc). Now your repository is synched with the latest changes and you can safely push to sync the central repository with yours.
In this case you have to pull first, which means that C will not be overwritten, since both repositories have the same version (remember, you only changed B on both repos).
In the case of B, where you have two divergent versions that must be merged by git, there might be conflicts. But this is exactly what a pull is, it's a fetch (to sync your repositories) and a merge between your local branch that is tracking the remote branch, e.g. master is merged with origin/master.
And finally the same thing will happen to A, the changes made in the first repo to A will be a trivial merge into A in the other repository, since the modified A is modified from the same version (identical blobs) of A in the other repo.
Hope this cleared some stuff up.
Cheers!
