Compared to what came before it, I really don't see how the interface is any less intuitive or documented compared to svn or cvs. For example, see the sections for the checkout command for svn[1] and cvs[2]. And then there's the man page[3] for the git-checkout command. The git documentation is a bit more detailed.
Git checkout is overloaded with too many behaviors. If it was naturally intuitive they wouldn't have needed to add the restore command. A better comparison would be Mercurial which has a much more coherent command interface.
Given the widespread use of git now, it's probably the first VCS that people are exposed to. But, for several years after it was released, it was the first distributed VCS that people used (if they hadn't had a chance to work with other DVSs like mercurial or bazaar). So, it's likely most people at that time were used to using svn or cvs.
As for overloading the checkout command, the git man page lists the following
1. checkout a branch
2. checkout and create a new branch (combining git checkout and git branch)
3. checkout a path at a certain commit
In contrast, the svn co/checkout command has the following options
1. Checkout a directory
2. Checkout a file
3. Checkout a directory or file at a certain revision
Which really isn't that different. Given svn's concept of branches really being copies of the repository, one would switch branches by just checking out a different branch by using the switch command. In this case, I think git's interface is better since you don't need a different command to just change between branches.
I'm speaking about the concepts that underly the interface, not the details of options and so on. svn was orders of magnitude better: you checked out a repo, you made local changes, you got to see the changes you made before committing, you committed changes, unless there were conflicting changes made in the meantime in which case you had to assert that you'd resolved those conflicts, possibly with help from merge tooling.
That's it.
Now, I admit that much of the conceptual complexity with git is to do with it being a decentralized system. svn was not. However, I think it does a tremendously bad job of abstracting and conceptualizing that complexity.
> svn was orders of magnitude better: you checked out a repo, you made local changes, you got to see the changes you made before committing, you committed changes,
The only extra step that git introduced was pushing the changes up to the remote.
- svn checkout -> git clone
- make changes (same for both)
- see changes (svn diff -> git diff)
> unless there were conflicting changes made in the meantime in which case you had to assert that you'd resolved those conflicts, possibly with help from merge tooling.
Which is what you would have to do with git as well if upstream was updated and you pulled it down to your working copy with git.
> However, I think it does a tremendously bad job of abstracting and conceptualizing that complexity.
I think part of the problem is that people want to make getting changes from the repository and sending changes to the repository a single step, whereas git only did that for getting changes with the git pull command. There's no corresponding git push command that handled committing as well as pushing the changes to the remote.
What should have been done was to never give that option. That is, the git pull command should not have been a thing and people would have to learn that there are two steps. One is the network operation of getting the changes or sending the changes and the other is to apply those changes to the working copy or staging those changes in the working copy before sending them over the network.