Definitely I can see the appeal of branches for software you ship, where you need to bug fix an old version and release a patched ver etc, but I can't really see the need for web based software, which I think is pretty usually developed linearly without much mess.
I much prefer doing branches in the source code (If that makes sense).
For example say you have a widget and you want to try a different strategy, create a newWidget in the source, make it so you can swap it in and out of the runtime maybe for testing. Keep developing it, until you're sure it's cool. When cool, replace widget with newWidget. If it doesn't work out, just delete it.
Then, when you want to commit your branch, rebase the branch from your master before merging. Then, when you merge, the patches will show up all in a row at the point you commit, as if they were all done in a row. Essentially, this is exactly what happens when you are working with subversion for a couple of days and then do several commits at the end.
Except you can trivially have multiple of these things going at a time.
I'm going to ask you a question: Have you actually tried git or anything for a significant period of time, like, at least a couple weeks? (Not just "yeah, 5 minutes.") If not, I'd point out that you're speculating about how git might affect workflow to people who actually know how git affects workflow, since they are living it. (And if so, you're not doing a great job of showing that you tried it.)
Let me restate: I do not like branches and use them very rarely.
So, to the guy who hates branches, what does git offer me over svn (Which does all I need at the moment)?
The ability to version control your project (even without branching you can checkin) when disconnected (from your network).
Maybe that's a good selling point for people who aren't connected to the net much though,
Yeah Right :-P Obviously I meant if you were working on a project with its repository on a remote server. Assuming you want local version control (as you seemt o do, since you are locally installing svn) you'd maintain a separate local repository, maintain the same project under both, and synch them both when you get back online?
And if you had two laptops say (apart from the remote server) , you'd maintain 3 repositories?
Technically speaking, svn merge is more akin to cherry-pick in git/hg/etc..., where the "merged" commits are not recorded as such, but as totally new commits.
Note also that bad svn merging capabilities are specific to svn, not to centralized VCS (perforce, etc...). It is not so much that DVCS are better than svn as much as svn worse than everything else.