In fact, the only reason I use git instead of subversion is that I am required to do so.
Most people use git as subversion anyway, and when they mess the local development, re-create the local development.
No one wants to take a PhD in git command line flags.
* Syntax - in svn different commands use different conventions on how to use revision
* In svn moving directories breaks "subdirectory as branch" abstraction. I.e. there are no actual branches. Only files and versions of them.
* "Svn up" can fail, leaving working copy in broken, unpredictable state. This breaks abstraction, revealing that svn is little but copying files around. Git forces you to save your work and only then merge. That doesn't fail even when it fails to merge cleanly.
* ahem. All branches in SVN are copies of an existing tree at a particular revision. Call it a branch or whatever you want. But if you make a copy of your main development tree, you make a branch and you can work on it in the same fashion as if it was git. Merge it back to trunk when done or continue your work and sync with trunk or other branches. The principle is the same.
* Failing “svn up” is an unexpected technical problem that occurs due to problems with the server or network. The problem should never happen in normal cases.
https://edoras.sdsu.edu/doc/svn-book-html-chunk/svn.ref.svn....
Two styles of revisions is super confusing to users like me. Git confuses me a bit, but not in command syntax. Hope this illustration helps to see what I mean.
It even handles running multiple instances of git commands at the same time rather well.
Yep that's why i still use bitkeeper....and it's great :)