On source control anti-pattern I've run into is people thinking a commit is a 'save'. It's not. A commit should move you from one working state of your code to another. Compare that to saving my files which I do compulsively every 5 minutes or so regardless of the state the file is in.
I agree, but... It is nice that one can compulsively (or automatically) save, with full history. And then when things are in a nice working state, be able to distill this into one or more clean changesets.
`git rebase -i` makes this relatively easy/nice. I think even better tools for this would make it way more realistic to get away from the staging area as step in the default 'commit' process.
I agree it's not a save, but a commit doesn't have to be in a working state either, at least on a private branch. A commit is a rollback point which may not even compile.
So then why do I have the ability to stage individual lines of changes, creating commits that do not reflect a state that my system ever had, ergo was never tested or compiled in, thus can not be known to be working?
Also, what if I use a remote to synchronize between different machines I work on on the same code base?
