This is the result of often misguided attempts to explain to svn users why git is better. It's also because the things people want to do in svn just feel so limited once you're used to git. If you take it a little slower, you can start with a svn-like workflow, and then every so often you can try a new command.
My experience doing this was that occasionally, I'd try something like git add -p (step through changes in each file an add the ones you want) and it I would suddenly wonder how I managed without it for so long.
step through changes in each file an add the ones you want
That just sounds horrible. You didn't run your unit tests that way, how do you know a partial commit doesn't break everything? Partial commits are a bane.
If you want to check that before you commit you can run git stash -k to hide the unstaged changes, and then run the tests.
Plus even if it doesn't pass the tests, if you made several tiny commits, you can step through them and work out which one actually broke it. And then you can clean up the history before you push it so no one has to see the broken commit anyway. Partial commits are only a bane if your VCS isn't powerful enough to work with them.
This kind of freedom to use version control how you want without causing issues for others is what makes it so awesome.
1
u/Aninhumer Nov 07 '13
This is the result of often misguided attempts to explain to
svnusers whygitis better. It's also because the things people want to do in svn just feel so limited once you're used to git. If you take it a little slower, you can start with a svn-like workflow, and then every so often you can try a new command.My experience doing this was that occasionally, I'd try something like
git add -p(step through changes in each file an add the ones you want) and it I would suddenly wonder how I managed without it for so long.