You still gotta type the message.

I think the original poster was referring to staging the commit as their "thinking" step, not composing the message.

Personally, my workflow is to make many changes, then use `add -p` and `commit` to create a series of small commits. While staging, you might decide that you don't want to commit some bit of code and `restore -p` to toss it away.

I think your workflow would work well if you see commits as "development checkpoints" rather than semantic patches. It's not an invalid workflow, just a different one.

I'm sure you could configure VSC to be analogously ergonomic for any git workflow. But people who are comfortable with git and their shell of choice tend to develop comfortable workflows in the terminal as well.

For what it's worth, you can do similar to "add -p" in VSC by using "Next Change" to scroll through a file in the diff view and adding hunks with individually with "Stage Selected Ranges".

It's a little slower than "add -p" but serviceable. Having editable diff in the diff view is really nice though.

Taking time to consider things is good; but that doesn't mean you're better off with slow tools.

If developing has some loop like "consider -> implement -> evaluate", then the quicker you can implement it, the more budget you have for considering the problem.