FWIW, I learned git much faster than I learned svn and cvs, and found it far easier to use and understand the underpinnings of.

Svn in particular was so awkward to port diffs between branches and carry diffs forward in time (git equivalent of rebase) that I built a system of shell scripts around patch files. Instead of creating a branch and committing changes (so painful to create or switch branches in svn), I saved the working state diff as a patch file and reset the working directory whenever I had to switch to a different task. I had a couple of shell scripts, one to save the current diff and reset, and another to apply a diff to the current working tree. And I had a third one to do a three-way merge to resolve conflicts when the tree had been updated since the patch file had been created.

Git is the first SCCS I used that made sense.

Yeah, my SVN mode of operations ended up being multiple checkouts of the repository in directories alongside each other, one for each simultaneous task.

Ditto. Switching between branches in SVN was painful. We would use branches, but it was definitely a necessity to have a few separate instances with the main branches I might have to use pre-loaded. (Also a lot more work just got done in the "trunk" than ideal, just out of expediency.) Git is a huge improvement.

Svk made things a little better. But not much.

The interface for git is a bit of a mess, but the simplicity of the model (I tend to think of it as "a DAG of commits", YMMV), and the wizardry that makes that model consistent with the underlying nastiness of files and merging and whatnot, more than make up for the interface badness IMO. It almost always does exactly what I want it to do, or halts in a state I can easily move forward from, which is more than I can say for other VCSs I've used (mostly subversion) in all but the simplest use cases.

Without the right mental model, I expect git would be very difficult to use. I might not recommend it for a team I didn't think could grasp the concept of a DAG. Then again, such a team will basically be cargo culting every moderately complex technology they use, so what does it matter if their "committing_notes.txt" file contains git commands or something else?

This is a bad argument because there are tools (i.e. every other DVCS) that achieve the same effect without the interface problems.

A bad argument for what? I'm responding to a guy who said that git is harder to learn than UNIX and that teams new to version control should prefer CVS over git.

Are you criticising just git or DVCS? If the latter, try Mercurial if you haven't already used it.

I wouldn't, and I'd tried using Mercurial for my personal random projects for a while. I gave up not because hg is inferior, but because when python, the language hg's written in, chose to migrate from hg to git, the war was truly over and lost.

At the end of the day, a VCS is just a tool, one of many that I need to learn and use to do my job, and it's not worth the effort to learn both git and hg.

Somewhat related anecdote: years ago I decided to learn Dvorak, but eventually switched back, because by the time I'd become proficient, my ability to type in QWERTY's completely gone. From what I'd read online at the time this was unusual: most people who learned Dvorak could switch back (& forth) within a few seconds to a few minutes. It took me probably a week or two to be able to touch type in QWERTY again, and maybe a month to get back to my original speed. And by then it was as if I'd never learned Dvorak at all.

Anyway, the point of the story is: maybe I just have shit memory :-)

I used Mercurial very briefly just to evaluate it; it's fine. I'm criticizing git. And i'm also saying DVCS in general is more complicated than the most typical use case of VCS.

Using Git for everything is like riding a bicycle with four derailleurs to pick up milk from the corner store. Granted, this is what I do right now; just because some technology is complicated or annoying doesn't mean I don't use it. But I wouldn't recommend it to others.