I'm looking for the reasoning behind invention of the staging/index area in git. This seems to be an extra step compared to other revision control systems. There must be a good reason for it. That's what I'm looking for.
Note: I don't need to know how to use it because I've been actively using git for a while now and understand promotion of content through staging to final cache.
The “Why is "git commit -a" not the default?” entry in the Git FAQ explains the most common reasons.
The index is useful for committing only some of the changes from the working tree.
Consider the following scenario:
You can use the index to make a commit that contains only the “bugfix” changes without having to stash away your “new feature” changes. You can even use
git add -p
to stage only a portion of the changes from each changed file.Some people avoid this particular technique because it lets you commit something that could not have been fully and independently tested (commit == “bugfix”, but working tree (and testing environment) == “bugfix”+“new feature”). Practically, if you are sure the “bugfix” and “new feature” changes are independent, then you should be able to effectively test the “bugfix” changes even though your working tree also has the “new feature” changes.
A potentially less objectionable use case involves carrying “local-only” changes around in a working tree without having to commit them. Say a repository includes a configuration file that needs to be slightly altered in your working environment (changing a username, an email address, etc.). You can use the index to stage and commit everything except your local-only configuration changes. The mechanism is the same as the prior use case; the difference is that it is usually easier to convince yourself that your local-only configuration changes are not dependent on any other possible change you might be making.