[tednaleid]

The index isn't the information on all your files (it's not the .git directory). The index is an intermediate holding location between the file system and actually storing all of those files as a commit in the commit tree. It's the current state of the proposed next commit.

Your description misses (or conflates) an entire tree of information (the HEAD tree), and it's arguably the most important one as it holds the whole of your git repo's history.

I didn't fully understand git till I read Scott Chacon's "A Tale of 3 Trees" which explains what reset is all about and goes into the details: http://git-scm.com/blog/2011/07/11/reset.html

I love git, but I do not think it's obvious or intuitive without some explanation. It's different than any other SCM I've used in the past. I created this presentation a while ago that I think highlights some of the real concepts that people need to know to really understand git: http://tednaleid.github.io/showoff-git-core-concepts/

[shadowmint]

Ok, not the index. The point is:

You have repository meta data in your .git folder.

You can download new information into your .git folder using git fetch.

...but you can only apply changes to your .git folder's data locally (eg. git merge)

...and you can only apply changes to your file system from your local .git folder.

Four, basic concepts. Why is this difficult?

There's tonnes of complexity in git, sure, if you have trouble merging after a rebase, sure, that's totally understandable.

...but the basic failure to understand the difference between applying a remote change directly to your current file system (not possible) and downloading that change and then applying it locally in various ways frustrates me, I've got to say.

[ams6110]

This might be best explained with pictures, which of course aren't really possible on a forum like this. The problem is when people try to explain git in words they often start talking about "directed acyclic graphs" and "local remote" or "remote local" branches (what?) and using terms like "clone", "checkout", "rebase", "master", "head", "origin" without defining them; terms that have specific meanings in git that are different from their meanings in other systems and different from what many uninitiated users might think they mean intuitively.

[anonyfuss]

> Four, basic concepts. Why is this difficult?

Because it's 3 more concepts than most people need.

A simple remote repository, coupled with a working copy, is easy to understand (and also all that most people really need).

You commit, you update. The only local divergences are the changes you haven't committed yet. In my experience, almost anyone can understand this semi-intuitively, and they only start getting confused when they hit merge conflicts.

Git, however, introduces considerable more state that a user must understand. There is local working copy state. There is local repository state. There is remote repository state. There is other people's remote repository state. Those states can become in conflict with one another, which means that there are quite a few more places to hit conflicts, and lots of sharp edges in the tool (git) with which you'd resolve them.

That's a lot of state, and it's state that most people don't actually need; it incurs a lot of mental overhead, even for people that understand how it works -- as evidenced by the fact that we're even having this conversation and two of you are debating how the index works.

The fact that this is git's default operating mode means that git is a bit like using a thermonuclear weapon to cook your breakfast, when most of the time, a simple gas stove would do. The tool was built for Linux, where it was designed to handle competing, divergent organizations, all of whom maintain long-term ongoing forks, with existing political and technical disagreements, divergent code bases and divergent ideas of stability and support requirements, all of whom are independently and concurrently maintaining, sharing, and rejecting patch sets across the graph of organizations participating in Linux development.

It's a huge, complicated, expensive, and messy development process, and it's nothing like what most organizations and projects need to support as their default mode of operation.

The problem isn't the people, the problem is that the tool is too damn complicated.