I think the biggest problem I have with git is that I don't understand how people can't get it. (That's assuming they understand DVCS, but don't get git. Not understanding DVCS is unsurprising.) It's like when my nonprogrammer friends who took CS101 didn't understand for loops. What?! It's just applying a concept you already understand.
It's unfortunate that git re-uses some verbs from cvs/svn with different meanings, but is that really such a big hurdle?
And I'm always surprised to hear complaints about git's user interface. I find the command-line interface far friendlier than others: auto-paging, colorized output, text hints of what I should do next, and fantastic tools (like bisect) in the same package.
And looking through my bash history, most of my commands don't use any options (the biggest exception is git commit). Possibly this is because I do most of my git interaction through vim-fugitive (and I have aliases for commonly-used complex commands). But I think it makes more sense to have a smaller set of commands that are logically organized (rebase mangles your history, reset re-aligns based on your history, ...) than a single command for every function.
It's unfortunate that git re-uses some verbs from cvs/svn with different meanings, but is that really such a big hurdle?
And I'm always surprised to hear complaints about git's user interface. I find the command-line interface far friendlier than others: auto-paging, colorized output, text hints of what I should do next, and fantastic tools (like bisect) in the same package.
And looking through my bash history, most of my commands don't use any options (the biggest exception is git commit). Possibly this is because I do most of my git interaction through vim-fugitive (and I have aliases for commonly-used complex commands). But I think it makes more sense to have a smaller set of commands that are logically organized (rebase mangles your history, reset re-aligns based on your history, ...) than a single command for every function.