I agree with @Harmelodic ... the term "Staging area" is probably most used and straight-forward.
For example, when using the git-add
command, you can say that you are "staging" content.
The term index
was used early on in Git's development but it was changed.
This is a good historical thread.
Snippits:
Commands that pay attention to the registered content of files rather
than the copies in the work tree use the option name "--cached". This
is mostly for historical reasons --- early on, it was not obvious that
making the index not match the worktree was going to be useful.
...
"cache" was an old name (and still established name in-use in the
code) for the index...cached to mean "look only at what is recorded
in the index".
...
Originally, the way to say "what is in the current working tree for
this path is what I want to have in the next commit" was
"update-index". "What I want to have in the next commit" is "the
index", and the operation is about "updating" that "What I want to
have...", so the name of the command made perfect sense.
"update-index" had a safety valve to prevent careless invocation of
"update-index *" to add all the cruft in the working tree (there
wasn't any .gitignore mechanism in the Porcelain nor in the plumbing)
and by default affected only the paths that are already in the index.
You needed to say "update-index --add" to include paths that are not
in the index.
A more user friendly Porcelain "git add" was later implemented in
terms of "update-index --add", but originally it was to add new
paths; updating the contents was still done via "update-index"
interface.
...
In short, "stage" is an unessential synonym that came much later