I've been using the staging area for a long time. It only makes me wish I could turn it off.

git is FUCKING HARD due to its tons of poorly designed misfeatures. The index/cache/staging area is the worst of them. If git wants to make any progress towards actual usability, this mess needs to be untangled with prejudice.

Other tools have none of this overly stateful bullshit. When I want a file to be included in the next commit, I don't want a silent, implicit copy to be whisked away into some interal storage the moment I flag it. There is NO reason why merges need to destroy the contents of that same storage area. The totally confusing semantics of the reset command with the three nonsensically named modes soft, mixed and hard are also created solely by this particular misfeature of a magical hidden storage area.

There is also no reason to even support destructive history editing. Immutable history is the correct choice. The mercurial evolve extension, for example, supports rebasing without destroying history.

Also, the combination of not being able to close branches instead of deleting them and not storing branch names in commits makes git history completely undecipherable when you have to go back more than a few merges. You might just as well throw it into the garbage bin.

Just take a look at competing tools (free and commercial) to see what's being innovated in this space and how this widespread obsession with git is in fact preventing much needed progress.

Early in my career I was a junior developer on a team using SVN. I knew git and used a git plugin that let it work with SVN. I would often talk about various branches and things I was doing locally in my repository and the other developers would get concerned, because making a branch is SVN is a big deal, and here I am, it seems, making tons of branches. It was fun because when I would finally upstream my work, it would dump a dozen commits into the SVN history all within the same second. It was kind of nice having the linear history forced by SVN though.

> that's just laughable considering SVN needs a central repo to work…

Do you use GitHub, GitLab, Bitbucket, gitea, ...? There's your central repo. If nothing else, it represents the “backup” facet of using an SCM.

>Once an SVN user discovers the magic of a staging area

You can already do that with TortoiseSVN or just through the cline

>stashes

SVN uses shelves

>git isn't hard

This feels like the "lisp is magic" argument that no one can seem to prove, despite how universal its proponents claim the law to be.