[mahidhar]

Agreed. One of the common things I use is git add --patch <file>. This allows me to commit changes in a file under different commits, by staging only the parts of the file that I consider as relevant for that commit. A lot of times I have different conceptual ideas in the same file, and I would have either forgotten to commit them during the day, and only realize it in the evening when it's time to push the code upstream; or those features would have been developed in parallel, because they are codependent, but are not necessarily the same from a conceptual point of view to the project. Either way I would want them under different commits so that my commit log is clean, and each commit can stand on it's own. This is where the --patch flag and the staging area are really useful. It might be a little trickier than just committing all tracked files with changes, but I appreciate the control. However, I do sympathize and agree with some of the points raised in the article, and I think there's definitely a scope for better interface design in git. For example, the stash is something that regularly confuses me, and the solution in the article seems like a better interface.

[4ad]

> A lot of times I have different conceptual ideas in the same file

Or debugging code. You're right, git add -p is a lifesaver.

[qznc]

The alternative could be `git stash -p`. Stash away the changes you don't want to commit, then commit everything still in the working tree.

The idea to remove the concept of the staging area to simplify git is worthwhile. I heavily use `add -p` myself, but newbies certainly struggle with it and teaching `commit -a` is not the solution.

[4ad]

> The alternative could be `git stash -p`

No, because I don't run `git add -p` before committing (I would run `git commit --patch` for that). I run `git add -p` during the development cycle. To emulate this with `git stash` would require a very annoying dance with stash and rebase.

> newbies certainly struggle with it

Newbies don't even know about `git add -p`. Newbies struggle with git because commands are not orthogonal (as the article mentions), and because documentation sucks. There is nothing inherently difficult about the staging area, it's just that it's not very visible what object a command would use or affect (index/tree/working directory) and it's hard to learn this.

The problem is with the implementation, not with the model.

Another problem is that in most cases people don't really want git, they want svn with local commits and better merging capabilities. Git is very popular, for some reason people use it even if it's clearly not what they want or need. To these people I suggest they should use the DVCS features of Perforce.