Opinions obviously vary. The staging area is one of the most useful things about Git for me, and I use it just about every day.
git commit those three files
Personally, I use staging area all the time to create a curated set of commits that make logical sense when putting them up for review.
My workflow is generally to keep a very messy history of `XXX` commits until I am happy with what I've come up with. Then reset back to the branch point and using the staging area to build up logical changesets.
I don't care about the history of my coming up with the solution, I care about presenting the solution in a way that makes sense to reviewers, including future me.
Later on, if I notice that I messed something up, I'll create a fixup commit and do an interactive rebase to squash it back into the correct commit.
It should be a crime for people to blindly stage everything. Cleaning up after my colleagues easily falls under the "lost cause" umbrella.
If I really care about things being fully correct at each commit, I'll do an interactive rebase and just stop and test on each commit.
Often they're disjoint enough that I'm confident that if the end result works, the intermediate commit works, as the sibling commenter mentioned. (Even if not, on many teams it all gets squashed anyway, the intermediate commit message just makes the Pull Request easier to review.)
I can also often easily comment out the uncommitted stuff.
Finally, if I'm really worried about it, after creating the intermediate commit I can just `git stash`, test it, then `git stash pop` and keep working.
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.
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.)
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.
Take a look at the research by the gitless folks: https://spderosso.github.io/oopsla16.pdf, https://gitless.com/
Truly jumped the shark.
This study design is a real problem -- even after I have read the paper, I am not convinced that I should be using gitless. Their graph looks science-y, but the small sample size and non-representative experiment design means the conclusion do not apply to my work.
Reading this paper is reading a DB benchmark which only used rows with two integer fields in all their tests. Sure, it is interesting reading, but unless your workflow is exactly that, it is useless in real life.
(Disclaimer: it is entirely possible that gitless is better than git in all workflows, not just the one described in the paper. But even if it is the case, I would not know about it, at least not from the gitless site.)
So yeah, feel free to leave it out of your implementation; it doesn't seem like something that'd fit into the plan9 mindset anyway. But it is removing a very useful tool to some people.
1. Make exploratory modifications
2. "git add" pieces that I think are "commit worthy", even if I'm not sure I want to actually commit it yet (still exploratory work).
3. If I decide I don't like the latest set of modifications, I clear them all, going back to what's in my pseudo-commit.
4. Once I'm happy with it as a whole, I turn it into a real commit, complete with message.
What would be really nice is some sort of "pseudo-commit stack" whereby you can do this workflow, but every mini-commit goes into a stack that you can unwind to whatever point you want if it turns out that you've been going down a blind alley. If pseudo-commit stacks had first class treatment, you could even stash them, which would be great if some other emergency came along that you had to deal with now.
Internally, you could create some kind of HEAD-like pointer for this, store commits that go from HEAD to PSEUDOHEAD, and then when you're finally ready to commit, squashes everything from HEAD to PSUEDOHEAD and follows standard commit procedure from there.
Or maybe you could implement it as a "reset HEAD" kind of thing to collapse the pseudo-commits, which then allows you to use standard partial commit semantics if needed.
Actually, now that I think of it, I could do a poor man's version by tagging REALHEAD before I start, making actual, real commits as I go, and then "git reset REALHEAD" to start building the actual commit I want...
Mercurial patch queue is pretty much that. You can also use temporary commit and phases to ensure they are not visible from outside your local repository.
I have never really understood why git introduces all this weird concepts (staging, stash) for what are just temporary commits in the end.
I use branches for this, and private remote repos. I thought that stash was magical and cool until that time I stashed in the middle of a merge and dug into the details of stash...
If I hate the state of my experimental branch, I kill it. If I want to keep parts, I cherry-pick them over to another experimental branch. When I want to keep fractions of patches, I manually copy deltas across with git-difftool (which was the only real reason I was stashing anyway). And when I finally have a branch that I'm happy with keeping, then I use "git merge -i" to collect the mini-commits into a sensible history
Sometimes, you want to have a temporary snapshot, but not a commit.
So I write some code, it works, but I'm thinking of trying some things out. I stage the working code and make more diffs. Now I can have my editor show the diffs between my stage and my new changes. And I can easily rollback individual files or re-stage some more files.
Until I am satisfied. And now decide to make a commit.
I could just make them all commits, and then do a interactive rebase as well. And I do that too. But sometimes the staging area is just simpler and quicker. With git status I can see it at a glance. Etc.