> I think the whold concept of stage/index/cache is completely unnecessary though
I was thinking the same for many years. But lately started to use VSCode for some projects. To see how staging is integrated there was almost an enlightening experience to be honest. All it takes to make staging an extremely useful feature, compared to all the other IDEs, is a slight change in how diffs are presented: In VSCode line-change markers indicate only a diff between working tree and cache (and not working tree and HEAD, like "everywhere" else). After staging a file in VSCode all inline diff markers disappear and the file looks like it would be unmodified. Than, new changes on top of the staged stuff will result in line change markers and inline diffs (showing only the unstaged changes). This way one can track "changes on top of changes" without having to commit the intermediate steps. This makes building up even big commits quite convenient as one can do it in small steps, having a (directly visible) diff of manageable size at any time in this process.
You don't need an extra cache level for that. If what you want is to accumulate "adds" one at a time into the cache to create one combined commit, you could just accumulate small commits until you had what you wanted, then merge the commits into one combined commit before pushing to the server.
This approach doesn't allow you to easily revert parts of your last change-set. Actually you can't even distinguish in the diff your last changes form all the other accumulated changes once the recent change-set was commited.
I don't follow. You could totally implement a staging area workflow by making a commit with the message "Staging Area", repeatedly amending it, and then finally giving it a real message when you're ready to commit "for real". The main thing you lose that way is the ability to push safely.
I was thinking the same for many years. But lately started to use VSCode for some projects. To see how staging is integrated there was almost an enlightening experience to be honest. All it takes to make staging an extremely useful feature, compared to all the other IDEs, is a slight change in how diffs are presented: In VSCode line-change markers indicate only a diff between working tree and cache (and not working tree and HEAD, like "everywhere" else). After staging a file in VSCode all inline diff markers disappear and the file looks like it would be unmodified. Than, new changes on top of the staged stuff will result in line change markers and inline diffs (showing only the unstaged changes). This way one can track "changes on top of changes" without having to commit the intermediate steps. This makes building up even big commits quite convenient as one can do it in small steps, having a (directly visible) diff of manageable size at any time in this process.