I don't even get to code that much and I've found very compelling reasons to do all of: - git rebase -i (the "cleaning" of history) - git add -p (which requir

I don't even get to code that much and I've found very compelling reasons to do all of: - git rebase -i (the "cleaning" of history) - git add -p (which requires a separate staging area) - Using a bare repository (which, just for the record, I've also had to do with SVN, but we didn't have a special Googlable term for it) - Track the difference between a local and remote branch (this is actually inherent to DVCS workflow, it's like going from DOS to UNIX and complaining that they make you track file permissions... you didn't even have the option on DOS!) It's actually kind of embarrassing to see an SVN user claim that they don't understand the difference between a downstream concept of a central repository and the remote concept of the same repository, because I can sure as hell remember having to run "svn up" before "svn ci" just in case someone had made a commit to the remote repo in between the time of my last update and my upcoming commit. master, "origin/master", and origin's own master all have corresponding concepts in SVN, even if master and origin/master had to be the same by definition. One more thing: I'm pretty sure SVN now has only one .svn directory, just like git.