If your commits are not referenced by a branch or tag, then those are eventually committed. Having to have a branch to keep the commit around means you need to come up with a name for it if you ever want more than one name. When I go back to Mercurial, it's actually quite relieving to not have to come up with a short name to describe what the current work branch is doing, only commit messages.

And no staging area is strictly simpler than having a staging area, which is contrary to your assertion.

When would you be creating a branch to do work without knowing what work you're doing?

It's not that I don't know what work I'm doing, it's that I don't know how to give it a unique name.

Sometimes, I try a few different approaches to make something work. Each of these attempts is a different branch--I might need to revisit it, or pull stuff out of it. Good luck staring at a branch name and working out if it's landloop or landloop2 that had the most working version of the code.

Super late, but I think a good approach would be to use an issue/work tracker of really any flavor (even manually), log all of your to-do headings as issues, and then just name each branch after the associated issue/job number.

> Isn't staging area actually a feature?

I've been using git for a few years, and staging has been all cost with zero benefit so far.

"Isn't staging a feature?"

Well yes, but the GP is claiming that git is the most simple thing above file storage.

Staging may be a feature, but it adds complexity. Perhaps useful complexity, but complexity nonetheless.