I don't know about you, but I often get sidetracked with different changes when I'm working on something, so that the work directory is in a messy state to commit everything. The staging area allows me to cherry-pick only the changes that will be in the next commit, while keeping the rest for later. This way you can save the state momentarily, finish polishing the changes, and then easily commit them. I find it very useful to keep focus on what I'm currently working on, without the overhead of WIP commits.
> By cherry-picking changes from workdir into a commit don’t you basically make a blind guess?
No, you use the interactive mode (`git add -p`) to select exactly what you want.
If you overpicked, you can reset a single file, and try again. That can be a bit annoying if there are a lot of changes, so this is another reason to keep commits small and atomic.
I think the answer to the question is "yes, the person staging a partial commit may be making a guess". I think this is because the tool apes an earlier practice of crafting patches to share with other developers. There are definitely cowboys writing patches to show others, and not necessarily testing every implied snapshot in a chain of such patches. Some CI practices also encourage cowboy commits, i.e. if a team pushes commits to get them tested rather than testing prior to commit.
You can imagine an inverted perspective where the stash should be the only non-staging area, and the working copy _is_ the staging area for the next commit. Stash away partial changes you want to defer, then test the current working copy, then commit the working copy.
You'd also want status/diff commands that let you more easily compare: working vs HEAD (what can be committed); stash vs HEAD (all uncommitted changes); and stash vs working (deferred changes).
> By cherry-picking changes from workdir into a commit don’t you basically make a blind guess?
No, you use the interactive mode (`git add -p`) to select exactly what you want.
If you overpicked, you can reset a single file, and try again. That can be a bit annoying if there are a lot of changes, so this is another reason to keep commits small and atomic.