How else would you support breaking up a change into multiple commits?

I’ve been toying with various ways to do this. Some alternatives I’ve thought of:

- a “draft commit”, where you can amend a bunch of changes into a commit before finalizing it.

- default to “git commit --all”, and allow the user to “git commit --patch” where needed

- as 'anthomtb says, `git stash push --patch` (I also find myself wishing for `git stash pop --patch` so you can shove bits in and out of a stash as needed.)

Isn't a "draft commit" the same thing as the staging area?

The main differences I’m imagining are:

a) terminology: it’s one less concept to have to wrap your head around; and

b) a draft commit would also have a draft commit message, and (though I’m admittedly not sure about how well this part would work), draft parents (probably supporting refs rather than just commits as parents) so you can have multiple of them and shuffle them around conveniently. (This also sort of subsumes the stash as well.)

I made a preliminary stab at this a while back, though it has some awkwardness and I haven’t had a chance to revisit it recently: https://github.com/wolfgang42/git-draft/

By making multiple partial commits, then squashing stuff together as needed. Or amending the top commit. Or amending non-top commits (making them "absorb" the changes).

Which is what I do with mercurial (& evolve), and I am happy I don't have a super-special extra concept to clutter up my already overflowing brain.

The way I think of it, the staging area is an incrementally buildable commit that is not called a commit because commits aren't incrementally buildable. So if you allow commits to be incrementally buildable, then you don't need the staging area. The only difference is you need to come up with a message for the commit when you first start to build it. Or not—make it empty, then amend it when it becomes something worth naming.

The main thing in my book would be to call it "the staging area" from the start and stick with it.

The point of the comment is that all 3 terms refer to the same thing. `git add` modifies staging area, `git diff --cached` shows the diff of things in the staged area, and `git stash --keep-index` stashes things that haven't been staged (I think? IDK, I never use it). Maybe pick one?

Instead of git add --patch, there could be a --patch option to git commit. You can already edit the latest commit with git commit --amend, so you'd have to do git commit -p to get the commit started, and then continue with git commit --amend -p.

`git stash -p`

This. I stash what I don’t want to test and commit, because I can’t build or test the staging area.