Another secondary thing that's very convenient for me is that I can make many small changes and push them all at once when I'm happy with them--because they're small they're easier to review. But this is a workflow issue, it's not that one couldn't do this with SVN.
This is part of the problem with DVCSes - you do your work off in a cave, and then when it's "perfect" you submit it for inclusion.
Note that SVN doesn't lack this problem - it can even make it worse. It's just far more common in my experience for people to do work in a cave somewhere with a DVCS and then throw it all over the wall in a huge hunk than with SVN, because it's so easy to maintain that fork off in neverland.
After all, just look at the comments (on this article no less!) about how "once I clean X up, I'll put it on {github,bitbucket,google code}." That's the kind of attitude that means it'll almost never (statistically) be seen by anyone other than the original author (which is likely true anyway, only one of my projects has ever really attracted anything resembling attention).
Note that Ben isn't convinced that this risk of DVCSes outweighs their (admittedly large) benefits. It merely aggravates a very serious problem to a point where it becomes a complete nightmare.
My experience has been that the alternative to many small commits, occasionally batched (because who really wants to look at "cleaned up Checkstyle's warnings" endlessly?) is one big commit two or three times a day, which is significantly harder to digest. But in any case, as you allude to in your response, this is a social problem. I contend that the sort of people who work in a cave somewhere with a DVCS and then throw it all over the wall in a huge hunk would either do that anyway (see Linux kernel features before they make it into the mainland trunk for evidence; this was going on well before git, and if anything git has made it less of a problem) or wouldn't contribute at all.
This is part of the problem with DVCSes - you do your work off in a cave, and then when it's "perfect" you submit it for inclusion.
Note that SVN doesn't lack this problem - it can even make it worse. It's just far more common in my experience for people to do work in a cave somewhere with a DVCS and then throw it all over the wall in a huge hunk than with SVN, because it's so easy to maintain that fork off in neverland.
After all, just look at the comments (on this article no less!) about how "once I clean X up, I'll put it on {github,bitbucket,google code}." That's the kind of attitude that means it'll almost never (statistically) be seen by anyone other than the original author (which is likely true anyway, only one of my projects has ever really attracted anything resembling attention).
Note that Ben isn't convinced that this risk of DVCSes outweighs their (admittedly large) benefits. It merely aggravates a very serious problem to a point where it becomes a complete nightmare.