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?
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.
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?