[jcranmer]

Have a commit command line that lists only the three files in question. It's really not that hard. If you're going to suggest more complex scenarios, the answer usually boils down to in practice "you want an interactive commit anyways," with perhaps some form of (unpushed) history rewriting to move patch hunks around between different commits.

The staging area is basically a half-baked, special commit that is easy to do manipulation on but hard to figure out what its actual state is (e.g., show me only the diffs that are in the staging area, or let me figure out what the hell is actually going on if I'm doing a complicated rebase). You know what would be better? Turn the staging area into a full, real commit and lower the friction of editing unpushed history to make it easy to move patch hunks in, out, and between these commits. It would help people who want commits to be atomic and therefore break WIP changes into multiple commits before publishing them for review.

[deathanatos]

> Have a commit command line that lists only the three files in question. It's really not that hard.

And how would you stage & commit only a portion of the changes made to a file?

(Like the parents, I use the staging area daily, and I am quite thankful for its existence.)

[ori_b]

> And how would you stage & commit only a portion of the changes made to a file?

I wouldn't. That code is untested, and I have a thing against committing untested code.

Git stash -p, on the other hand, allows me to select what code should be left in the working directory for testing, with no need for a staging area.

[pytyper2]

We just assume that when we commit, the code has been tested in the local dev environment. Better not be committing untested code to my repos, that will get you reprimanded.

[war1025]

`git diff --cached` shows what is in the staging area

[slavik81]

There's an alias, `git diff --staged`, that I find a little easier to remember.