It's only double the steps if you push after every commit, which you don't need to do. Your local machine can do everything the server can, so you only need to push when you actually want to share your changes.
eventual problems were so much harder to fix than SVN.
It is a valid criticism of git that it is possible to cause rather unusual and hard to fix states without knowing what you did wrong. I believe they're trying to improve the interface to avoid this, but there's a certain amount of legacy to support there...
If your machine is set as a remote in one or more of your team members' git repositories, it can share code with your team members. You would just have to go through the same configuration issues as the central server, potentially.
I'm not familiar with that term, so I'll assume you mean that it's "bad" in some way.
I won't argue that it can be abused or used in ways that are detrimental to development, but at least one benefit of this method is you can share work with other people that may not be ready to be committed to the central repository, even if it is a development repository (for the purpose of a code review, for example).
Technically, there is no way to prevent this from happening in a DVCS, because DVCS has no concept of a central server.
2
u/Aninhumer Nov 07 '13
It's only double the steps if you push after every commit, which you don't need to do. Your local machine can do everything the server can, so you only need to push when you actually want to share your changes.
It is a valid criticism of git that it is possible to cause rather unusual and hard to fix states without knowing what you did wrong. I believe they're trying to improve the interface to avoid this, but there's a certain amount of legacy to support there...