Without branching, you can only have branch-like behavior by having multiple checkouts.
You say that as if it were a bad thing.
Yes, I have multiple trees for multiple projects. Why on earth would my life be better if I didn't?
Presumably you're not saying something such as "one directory tree for multiple projects is better than multiple directory trees for multiple projects"; that's just the moral equivalent of tabbed browsing vs. non-tabbed browsing, and some people quite legitimately don't find tabbed browsing to be an improvement for them.
And when you go to resolve those (at least in Git) you will still be doing a merge operation that is identical to merging a branch.
A "merge operation" that I actually bother to notice is what happens if somebody else changed some stuff in ways that collide with my changes. If that happens, it's my job to figure out what to do - including "discard my work because their changes do it better" or "discard my changes because their changes make my changes no longer necessary".
How would branches make a positive difference there?
When you have multiple people touching the same project, branching helps keep people's work separated so they aren't tripping over each other,
There is precisely one person touching my repository, and that's me, so there's nobody to trip over. Other people's work is separated from my work by being on other people's machines. The ultimate goal of all of our work is to get our changes into the official common repository on the trunk or a release branch; how do branches either on my machine or in the common repository simplify this task?
and merging provides a place for reviewing and synchronizing changes across different efforts.
Either the merge produces no conflicts - or it produces conflicts, in which case I have to resolve them, as per the above. Again, how do branches improve things here?
Event CVS and SVN have branching because it is useful.
Yes, but "having a branch for fixes to a stable release line", to keep feature work for the next release separate from fixes that go into stable release lines (possibly backported from the trunk), is different from "branching for every change you're working on". The former is useful to the project; I've yet to see any scenario in which the latter is useful.
(And, yes, I've worked at a company where you'd check your fixes into a CVS or SVN branch and have somebody else merge it with the trunk. Perhaps it worked for the organization, but it was just a nuisance for me. I did most of my work on a checked-out-from-the-trunk tree, and created the branch when it was time to submit.)
You are complaining that you refuse to use one of the very key features of Git, and that somehow that refusal on your part means that Git is hard to use.
No, I'm complaining that fans of Git seem to think that, because they believe that some particular way of using Git happens to work better for them, it's the Right Answer For Everybody.
