| What part, exactly, is so hard to understand? All the examples he gives aren't particularly hard to understand. For example, he complains that git pull is actually git fetch and git merge... well, that's pretty obvious. First you have to fetch the changes, then you have to merge in those changes. What is particularly illogical about that? Another example: he complains that git branch combined with git checkout is git checkout -b (he forgets to note that you specify a branch name...). What's so non-obvious or "insane" about that? First you create a branch with git branch newbranch, then you checkout files from a branch with git checkout <branch>. The obvious shortcut is git checkout -b newbranch <branch>: when you want to create a new branch, then you have to checkout the files from a branch, and the -b creates a new branch for you before you do that. The only real thing that is a little tricky to understand is the concept of refs, but even that's not really that hard to understand. Every commit has a SHA-1 reference to it, and a branch is merely a reference to a particular commit that is the head of a line of work. Remote refs are about the only other type of ref that you need to know about - all they are is a reference that points to a remote repository that you can push to or fetch from. Once you know what a ref is, most of the man pages make sense. Thus when the man page for git-push says: git-push – Update remote refs along with associated objects
... you can see that it means that it will update the remote refs (remote repositories you are pointing to). Which is what he says in his article, but all he has to really do is understand what a ref is and he wouldn't be so confused.When you think about refs, they make logical sense - all they are is like a "remote branch" of your repository. As for complexity in the concepts, let's look at what he's complaining about: ...you have files, a working tree, an index, a local repository, a remote repository, remotes (pointers to remote repositories), commits, treeishes (pointers to commits), branches, a stash 1. Files - obvious 2. A working tree - you do your work in the working tree 3. An index - once you have made your changes in the working tree, you commit your changes to the index 4. A local repository/a remote repository - this isn't a particularly hard concept to understand. You do you work in your own local repository. You might get that repository from someone else. You make your changes in your own repository, then you push those changes to a remote repository. Not entirely sure what is so difficult about that concept... 5. Remotes - again, not a particularly hard concept really, as he says these are just references to remote repositories 6. Commits - You work away on your code in the working repository (whatever directory structure you so desire). Then you commit it to the index. Which is not really any different to SVN, where you checkout a file from the SVN repository, then you make your changes, then you commit your change back to the repository. Explain to me again what is so hard about this concept? 7. Tree-ish - This is an extremely advanced part of git that most users may never encounter. You most certainly don't need do know about this, though of course it is always good to do so. 8. Branches - we are talking about source control? If so, what is the issue here? Branches are not really any different in git than any other source control system. 9. Stashes - an extremely useful feature. If you are in the middle of working on something and you want to switch branches, you normally don't want to commit those changes. So what you do is "stash" the changes onto a stack. You can reapply them later. Some excellent info can be found here: http://git-scm.com/book/en/Git-Tools-Stashing There... none of that was so hard, was it? |
No, it isn't since the words fetch and pull mean pretty much the same thing to most people.
>> What part, exactly, is so hard to understand?
Looking at the length of your comment...apparently a lot, for most people.
I've tried to like git, I want to like git, I don't get git. So ... in Eclipse at least I use EGit to help me make git usable. Even with that tool to make git easier to understand I still find it confusing (or confounding).