Jacob Keller <jacob.keller@xxxxxxxxx> writes: > I know we've used various terms for this concept across a lot of the > documentation. However, I was under the impression that we most > explicitly used "index" rather than "staging area". > > Additionally, I think there are many other locations which > consistently use "index" as the term already. Another reason why we would want to standardize in the other direction is because "X acts as Y" does not mean "X is Y". It is true that we (and also "newbie friendly" tutorials) often explain the index like so: "When working towards the next commit, you improve the contents a bit in the working tree, you 'git add' it to the index to make the contents of the index closer to what you want to have the next commit. The index works like the staging area." But that is not the only thing the index does. When "git merge" finds conflicting changes, it adds the contents for common, our and their variants to the index for the path. This is quite different from how you use the index "as staging area"; the index is being used as the "merging area". When "git clean" wants to see which paths it finds on the filesystem are not of interest, it consults the index, which acts as the list of paths that are of interest.