Interesting, that's definitely not how I use git. My current code is rarely in a shape that can be fully committed. It often contains additional stuff I did on the way (small bug fixes, TODO comments, debug printf statements, etc.) that I don't want in the commit. Very rarely do I type `git add .` Am I the exception?
My own setup differs in slight ways from what those scripts expect, and even where they match I like to do my own customizations. I don't want to commit those changes, and staging makes it easy to not do that MOST of the time. The rest of the time, it's a `git stash` dance, which I sometimes screw up and lose the customizations.
I've tried to manage the configurations a different way, such as by having a private branch with my own settings checked in, but that doesn't usually work out. I'm aware that the REAL problem is that my coworkers have checked in those settings to begin with, but I would counter-argue that the REAL REAL problem is that those tools don't have a good way to combine "settings that I override or that only I care about" and "settings that have project-wide defaults but are safe for me to override." (Visual Studio gets it close to right with its .xyzproj and .xyzproj.user files, but VS Code's single .vscode/ folder breaks down in shared repos.)
Supposedly, Meta has the data to support the claim that you (and I) are the outliers here. Staging is confusing to users, especially new ones, which is why jujitsu explicitly doesn't have staging.
On the off chance that you haven't already had this suggested to you on HN, I would suggest taking a look at JJ.
I use it in all my Git-underneath repos with `jj git init --colocate` (You can run that in a git repo and it will hybridize, or in a new folder and it will init and hybridize).
It doesn't have the staging concept, treating the working copy as just another commit (@), and to boot it snapshots the state of the tree into @ when you run any jj command, so you can use `jj op log` to see every intermediate state of your working copy at any time.
Commit is just `jj commit` with no staging mechanics, or `jj split` to 'split the working copy commits' (commit some, keep the rest in @).
Try doing the same in any other source control system…
not to mention the early "just clone it into a new dir" answer before lightweight branching ...
I stopped using it the first time I committed something I didn’t want to, over a decade ago, haven’t used it again since so I forget the exact invocation, but I think it was just “-a” or something.
Before it bit me though yeah, that did seem like a default I’d have preferred. Not any more.
`git add -p` FTW
Git is extremely predictable, but only after you thoroughly understand it. Until then, it seems to surprise you often and every time it happens you think you've lost data. Many times I've had collaborators who said "git ate my files" and I can usually get their files back in a few minutes. This makes them hate git because they cannot use it without having me on call, and they cannot be bothered to learn git thoroughly themselves because it's too damn hard.
Honestly this is one area I really like AI - so I can focus on the things I really need to focus on and not spend a bunch of time becoming an expert in things I don't want to be an expert in.