[philwelch]

> Why is there a staging area in the first place?

Because you don't always want to commit every change you've made or every new file you've added.

> If a commit doesn't push my changes to a remote repository, why do I care?

If I have my code in a working state, I'd like to save that "version" somewhere, so I can make a whole bunch of changes without worrying about whether or not I can get back to a working state. This is true even if no one else in the world has to read my code. This is the entire rationale of version control in the first place! But if I can do it just on my own individual changes, that means I can go back to a closer savepoint and not have to play the whole level over again if I screw up ;)

> Well, if a commit allows me to have a local history of changes that I may not want to have in the remote repository, why do I need to stage my changes? Why don't I just commit them and be done with that? Isn't the files themselves a stagind area? Isn't this all redundant?

No, because you still don't always want to commit every change you've made or every new file you've added!

Maybe you want to commit while you have Vim open but you don't want to add a bunch of garbage .swp files to your repo. Maybe you did two or three different things that aren't related, so you want them to show up as two or three different commits in the history.

From the perspective of a Subversion or Perforce user, it's not something you really think about because it's not even an option that you have. You effectively don't even have version control on your own machine. Your company has version control, but you don't. And in my personal experience as a Subversion or Perforce user, I frequently feel lost at sea in that environment because it's virtually impossible for me to reliably do things like:

1. Get back to a working state newer than the one I checked out of the repository after making lots of changes everywhere.

2. Make completely unrelated code changes at the same time without mixing the changes together. Maybe one change is blocking on a code review. Maybe I found an unrelated bug and want to fix it separately from whatever other changes I'm making. Maybe I'm second-guessing a certain feature addition and want to put it on ice while I do other things. Maybe someone reported a bug and I want to fix it separately from what I happen to be working on at the time. Whatever the reason, it can live in its own branch and I can come back to it later. I don't have to create duplicate workspaces in my file system, Git just manages it for me.

3. Turn a large, complicated code change into a series of smaller changes, each with its own diff and description which I can review more easily.

These are things I do every day. I would do them if I shared my code with a small team or with the entire world. I would do them if I shared my code with no one at all. Git isn't just for large distributed projects. It's for decoupling version control from version sharing or version verification.

In practice, the purpose of something like Subversion or Perforce isn't to help you as a programmer, it's to help the canonical owner of the code you're working on to do certain things, like rollback to past versions or make policies that your code has to pass code review or something before you can "check it in". Git handles all that too--some of it more effectively--and it has the added feature that even you the programmer can get the benefits of version control, too.

> No tutorial that I can remember does this. Not a single one.

The purpose of a tutorial is to help someone learn how to use Git. If you're not interested in learning how to use Git, why are you reading tutorials? It would be much easier to just start a flame war on Hacker News and wait for someone knowledgable to respond. I guess you figured that out yourself.

[prodigal_erik]

What disturbs me about that workflow is that your commits have literally never been tested because the staging area contents aren't accessible as a working copy. I for one am adamant about not littering my history with all my crap that didn't run, so I much prefer to commit the mixed work and then rewrite history to tease out and regress the independent changes. I pretty much always test and commit my workspace as-is, treating the staging area as an unfortunately visible implementation detail. It'd be easier if I could stash some but not all of my changes to get them out of my workspace temporarily, but this hasn't bugged me enough to figure out how to implement that.

[spacemanaki]

> It'd be easier if I could stash some but not all of my changes to get them out of my workspace temporarily, but this hasn't bugged me enough to figure out how to implement that.

Here, let me help you, from the examples section of `git help stash`:

"Testing partial commits You can use git stash save --keep-index when you want to make two or more commits out of the changes in the work tree, and you want to test each change before committing:

               # ... hack hack hack ...
               $ git add --patch foo            # add just first part to the index
               $ git stash save --keep-index    # save all other changes to the stash
               $ edit/build/test first part
               $ git commit -m 'First part'     # commit fully tested change"

A nice thing about Git's Swiss army knife nature: someone else has likely run into most problems you encounter, and have added the solution to Git porcelain.

[prodigal_erik]

Thanks for the very genteel RTFM. I think you've pointed that out before, I just mischaracterized the process as quarantining the changes I don't want yet rather than rescuing the changes I do and forgot the mechanics.

[philwelch]

> It'd be easier if I could stash some but not all of my changes to get them out of my workspace temporarily

It's literally called "git stash".

Aside from that, you can squash commits together after-the-fact. If it makes it any easier, you can squash a whole branch together all at once before pushing it out to other people. No one need be the wiser. The intermediate commits can just be temporary savepoints for your personal convenience.

[CrLf]

The point isn't about me reading tutorials to learn Git.

The point is about convincing people to use Git by pointing them to tutorials and have them come back with blank stares and "why do I need this exactly?" questions.