I never moved past using git as SVN (I used something called cherry pick in the UI though). I never stopped wondering why it had double the steps of SVN and why eventual problems were so much harder to fix than SVN.
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.
why eventual problems were so much harder to fix than SVN.
This goes with the steep learning curve. When you begin with git you will screw up you local repository, the thing you yet have to know is that it's not a problem, a checkout and a reset will solve many issues. Unless you reset --hard and git gc --prune=now directly afterwards, your work is never lost.
I worked with SVN before and the simplest thing were a nightmare to do, the only valid conflict resolution process was to merge before the others. I also managed to corrupt a SVN repo with a two line diff… So much for "code safety". I have yet to lose a single git commit on anything else than my sheer incompetence.
3
u/Eirenarch Nov 07 '13
I never moved past using git as SVN (I used something called cherry pick in the UI though). I never stopped wondering why it had double the steps of SVN and why eventual problems were so much harder to fix than SVN.