[borplk]

I think you are missing the point. The author is talking about unnecessary complications. Git is unnecessarily difficult to work with and understand. He is debating whether and how much of any of these is necessary. Sure we can spend time and learn it, but why should it require this much learning in the first place?

[rjzzleep]

it doesn't, try github for mac. i gave it to a friend without any programming or vcs experience and it didn't take 5 minutes to understand, but at the same time when i went to check it out i found it like hell on earth.

but when you oversimplify things for any advanced user it becomes hell. git was made from power users for power users. more precisely to merge hundreds or thousands of patches a day. now you're telling people make it simpler, they're just going to laugh in your face and fully justified at that.

git has wonderful language support. it even has complete implementations in several languages. you want it simpler? hell just take one of those implementations and build it on top of that.

[chris_wot]

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?

[jebblue]

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

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

[chris_wot]

No, it isn't since the words fetch and pull mean pretty much the same thing to most people.

All I can say is that there are valid design decisions for seperating the two. That's why they created the shortcut - to make it easier to do what folks intend to do. When people do a pull, then they get what they want. That is the common nomenclature of git, pretty much everywhere.

And to be clear, the man page for git-merge can't be any clearer:

  git-pull - Fetch from and merge with another repository or a local branch 

Looking at the length of your comment...apparently a lot, for most people.

Which I would argue is because they are coming from SVN, and apply their experience with SVN to git. That's not really a problem for git, IMO, but more an issue for those who believe that SVN is the only way to go about doing source control.