> I like the ability to make a big, complex change and checkpoint stable portions (subsets) of the work as I go.
However, it does not replace all use cases of the staging area, which is why I gave it only as an example.
Of course, `commit --amend` with `-p` could solve your problem as well.
Alternatively, “create a new, 'pending’ commit, without a commit message, don’t point HEAD to it yet, and change most of the commit-related commands to modify this commit until it is finalized” also solves all the use cases of the staging area, because that is what the staging area is, but it is presented in a much more confusing way and ends up being yet another new concept for git beginners to grasp.
After thinking about this more, I find myself agreeing that in terms of beginner friendliness, the combination of incredible name confusion and the relative paucity of use cases where it’s necessary make the staging area an interesting area for significant change in the git defaults.
If I’ve got a big change which I want to split into three small internally consistent changes, with each change overlapping in many files, how in the world would --amend help?