I used `git add -p` until very recently (basically, until we built this feature in Zed). If you're using `add -p` and you notice a problem that you want to fix before committing, you need to go find that same bit of code in your editor, edit the code, then re-start your `add -p`. If you had chosen not to stage some preceding hunks, you need to skip over those again. Also, an editor can just render code much more readably than the git CLI can.

If so, would a better workflow not be the editor providing shortcuts to stage/unstage individual lines/hunks (which it can indicate in some state column) and a list of files with unstaged changes (to replace the inevitable `git status`)?

You get the same flexibility of crafting commits, directly from the place you’ve edited the files without having intermediate CLI commands. And all the other niceness of the editor (syntax highlighting etc).

Inside the editor in VSCode I would select a chunk that includes the markers that I want to stage, and stage them deliberately like you do.

For the actual commit often I have to do terminal because VSCode would fail to give me the relevant commit hook error message.