I’m reminded of the anecdote about make: Its original author used tab characters for indentation in Makefiles without much thought. Later when they decided to add make to UNIX, they wanted to change the syntax to something more robust. But they were afraid of breaking the ten or so Makefiles in existence so they stuck with the problematic tab syntax that continues to plague us today.

For at least four or five years, --staged is a synonym for --cached. I was surprised to see that --cached is not already deprecated.

Linus called it the cache. That’s the logic.

The author seems like a nightmare (what other kind of person lists out, in extreme detail, the number of people that agree with them?

I get where you’re coming from, but in this case, I don’t think so.

The author’s argument is not “I have an opinion, it’s right” but “I have an opinion which nearly the entire community shares, save one key person”. If you want to make an evidence-based case for that argument, you pretty much have to do something like the accounting that he did. Or appeal to general polling results – and you’ll notice the article links to such a poll, presumably to collect such evidence.

My good faith question to you would be: What other tactic do you think he should have taken, given the history here, and the case he wants to make?

Yeah, I’m slightly conflicted as the submitter. I think he definitely has an axe to grind and you can feel it, but it’s also a useful summary of one of git’s major UX issues and why it doesn’t get fixed, even if he’s framing it like he’s a victim here.

When I commit something, I want to see what I have (in git diff) first and then commit specific files (or –all or even –patch for parts of files). I never want to use the staging area. Can I turn it off?

You can try to adapt your habits and configuration. E.g. you can configure an alias for git add -A && git commit [...] (see https://stackoverflow.com/q/2419249/)

I wish the staging area didn’t exist.

I like it.

It allows for easily splitting the current changes into multiple commits. I often use git add -p to interactively select what should be part of the next commit while keeping everything else around. That can be temporary comments for what I’m going to work on next or just stuff that should be in a separate commit. Sometimes it makes sense to work on a set of changes as one work unit, but structure it differently into review units. To test & commit what is currently staged I can do:

git stash save --keep-index
do_my_tests
git commit -m "Fix foo"
git stash pop

Even when I want to commit all current changes, I like using git add -p to review them, especially if I have touched multiple files. “Changes in foo.ext? I just did those, stage the whole file (a). Changes in bar.ext? I did those an hour ago, let’s confirm those one by one (y)…”

(I also use a lot of aliases, so for me git add -p becomes g ap, git stash save --keep-index is g ss, git diff --patience --cached becomes g dc, and so on)

(I would prefer a consistent use of “staging area” and “staged” everywhere.)

Agreed. Mercurial gets along just fine without it and is a much easier to use DVCS system.

Yes, index/stage interactions with diff only comparing the working tree is one of the biggest git footguns. It makes me only stage files until the absolute end before I commit.

But according to documentation if you will do git commit <pathspec> then it will ignore staging area (named index there):

When pathspec is given on the command line, commit the contents of the files that match the pathspec without recording the changes already added to the index.

And if you want to be able to review what will be committed, then just use --verbose flag for git commit or set it to be default via git config --global commit.verbose true.

What behavior are you suggesting git add should have? Are you saying this should record file names but not contents so a later commit just includes whatever’s there?

The git porcelain is a very, very thin wrapper of git’s own internal data model. Clearing up terminology could make it easier for people to understand git.

It matters because there’s a clear step to improve the documentation (of which Git’s is notoriously lacking already) and there’s no reason to specifically include a clarification around the term that all the tutorials use and thus that all new users learn it as.

If it were a matter of removing the term “index” from documentation then it would be bikeshedding, but we’re talking about adding the term “staging area” here. I doubt anyone would object to a permanent “index” alias for every relevant command, as long as there’s “stage”, too

 git clone https://github.com/git/git
 find git -type f -exec sed -i "s/git/nit/g" {} \; // And some more refactoring
 git commit -am "Fork git to nit"

Git is a dvcs after all.

No need to be authoritarian, you can always make your own fork. Or simply apply the patches.