I'm a fan of using the right tool for the job. If you can't use git effectively or it just doesn't fit into your workflow, then, hey, don't use it. But, having

I'm a fan of using the right tool for the job. If you can't use git effectively or it just doesn't fit into your workflow, then, hey, don't use it. But, having used both, I'd actually like to know... Why are these things (that the author is claiming git can't do) so important? For instance, is checking out a partial tree ever necessary? Is it that you'd want more granularity over what subsets of the repo you are storing locally? Is it that you don't want to have to set up a bunch of (sub-)repositories? I ask because... I once worked on a codebase that was so absurdly huge most of us couldn't store it all on disk at once. And it sucked. Hard. I WISH it had been started as a bunch of distinct submodules, with extension points baked into the core build system so it would be easy to add/remove sections of the codebase. But the product predated git. And SVN for that matter. (Granted, the majority of the issues we suffered -- nightmarishly complex build systems, lack of transparency into what changes are being made, a bottleneck of devs lining up to commit changes -- were caused by process issues, not source control. But the source control did absolutely nothing to help either.) I really understand the frustration when it comes to git. It took me a LONG time to wrap my head around why it works the way it does, because I wanted/expected it to work like SVN, where the repository is like a giant tree of files reflecting exactly what I see on disk, with different branches of code getting their own branch of the tree. Instead, git was this concise, magical pile of data structures that somehow kept causing me to break things whenever I strayed too far from a basic commit & push workflow. But then I changed jobs a couple times. And, for some reason, I no longer found git a huge pain. In part because it just started becoming more natural and I knew what kinds of things to avoid, but also because I decided to sit down and really learn what I was doing. For one thing, I began making more active use of rebasing. Initially so I didn't need a ton of useless merge commits to keep up-to-date with the master branch, but eventually as a way of tidying up my work on a feature branch (i.s. squash, reorder, amend, etc) to make the set of changes concise and easy to follow. When working locally on a new feature branch, my commit log went from looking like this: > okay one more try at part A [tests pass] > fixing typo [tests pass] > one last thing for part C [tests fail] > part B bugfix [tests pass] > fixing bug in part C [tests fail] > finishing part B [tests fail] > trying this again (feature A) [tests fail] > part C, work in progress [tests fail] > part A, I think [tests fail] ... To this (more or less): > part C [tests pass] > part A (final implementation) [tests pass] > part B [tests pass] > part A (initial implementation) [tests pass] ... Depending on who you are, you'll either love that, or you'll scream at my lying, revisionist git log before wrenching out your eyes and hurling yourself out a window. But, for me, for the team I was working with, and for the codebase I was working on, it worked WONDERFULLY. I found myself feeling like I really controlled the readability of my changes. Each of those commits could be submitted individually for code review with no problems, and even though I was wiping out a ton of minor changes, I could still preserve a record of alternate implementations in case we wanted to refer to them later. Anyway, this post has become a long ramble. But, suffice it to say, I've found git to be very freeing. I just had to give up any expectations about how the process would work, and let myself start forming a new process around the power and flexibility that git offers. I believe I could say the same for mercurial (though I don't have much experience on it). And I don't think I can say as much for SVN, though I'm sure it does have a few advantages. And if you're workflow really can't change... SVN certainly works for what it is. It's just not something I'd ever like to go back to.