Coming from svn, the skepticism here is really about distributed version control, and being heavily involved with the vcs at all. (Being heavily involved with s

Coming from svn, the skepticism here is really about distributed version control, and being heavily involved with the vcs at all. (Being heavily involved with svn, like setting it up and administering it well, is really not that easy compared to just using git, what's easy is just jamming stuff into svn, as long as there are no conflicts). Having a local repo and push/pull to any other repo is not a complication but a huge advantage. It lets you do things like commit while you are on an airplane, or share committed work in an internal team before pushing to trunk, or keep repo history even if the server dies in a fire. It lets you not have to worry about who can be trusted with commit permissions or not. Being able to commit all the time without pushing lets you keep revision history without checking in, so you don't end up with many copies of your working directories, or saving up changes before you are 'allowed' to commit. Since you can commit all the time, you can destroy the working tree trying things out and then bring it back if they didn't work. So let's not complain about having a working tree, local repo, or remote repo. The staging area makes it so that you don't have to complete all staging of many different files in one huge command. You can add/rm something, preview what's staged, and only commit when you are satisfied. In addition, CVS type merge is a pain while it is actually much simpler with git or hg. And being able to keep rebasing your private feature branch on a changing remote branch is a huge improvement.