And it hits the most important point of: Gitless tries to do away with the staging area, thus completely misunderstands Git.
By your statement, I also completely misunderstand git. That's entirely possible, but if git is so hard to understand that daily use for years doesn't lead to understanding, maybe it's ok to misunderstand git.
Well, I frequently see random things to fix while I'm working on a problem.
When I 'm ready to commit, I run `git status` and notice there's a file that's been modified that's unrelated to what I'm trying to commit.
A quick `git diff` later and I see what I did: fixed an unrelated issues. So I add that one file to the index, commit it with a relevant commit message, and then proceed to do a second commit—the one I had expected to do—also with a relevant commit message.
I do this 3-5 times a day, at least.
What if those unrelated changes are in the same file as a bunch of related changes that you've already made? Do you undo all the changes you've made in that file apart from the random bug fix and then commit, or leave them intact resulting in that bug fix commit containing changes that are unrelated to the fix?
For even more complex cases you could use "git add -i"; however, that command can be tricky to work with and I find it's usually not to helpful to get that far into the weeds.
Honestly, people for whom the command line UI is "too difficult" should just use a GUI client. That's the target audience for them.
The staging area is also known as the 'index' and the 'cache'.
(Git has a consistency-of-naming problem.)
I wonder how many git usability issues could be solved just by addressing this and this alone.