It seems more plausible that Gitless just disagrees with its utility, or at least finds dancing around it overly cumbersome for the default case.

I've been using git for a few years, and often wished I could eliminate the staging area. It's an extra step for every commit, and creates extra complexity for no benefit I've been able to see. I haven't seen a practical example of a use case that's improved by having separate add and commit.

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.

> I haven't seen a practical example of a use case that's improved by having separate add and commit.

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.

>there's a file that's been modified that's unrelated to what I'm trying to commit

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?

In that case you'd want to use "git add -p" which allows you to pick only parts of a file to stage for a commit. It can be crucial in crafting a really solid project / commit history.

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.

Atlassian has a nice UI for doing that visually, too. Super easy.

Honestly, people for whom the command line UI is "too difficult" should just use a GUI client. That's the target audience for them.

I do this kind of thing often too. To me this all seems like it could be handled at commit time. And more simply too.

How do you know that they misunderstand it, as opposed to disagree with it?

Okay, I referred to it again. Still not seeing where you know that they misunderstand it, as opposed to disagreeing with it.

I've been using git professionally for a few years, and other distributed version controlling systems for more than a decade. This is the first time I see the phrase "staging area" in relation to VCS. Could you explain why it's an important concept?

It's central to git. 'git add' puts changes in the staging area. Then 'git commit' commits the staged changes.

The staging area is also known as the 'index' and the 'cache'.

(Git has a consistency-of-naming problem.)

> (Git has a consistency-of-naming problem.)

I wonder how many git usability issues could be solved just by addressing this and this alone.

Please refer to the linked discussion. Various people ask about it and various people try to explain it (including me).