First, you're already using the stage whether you like it or not. Second, if you're making single commits for entire features, you are using git in a way that is not optimal. git operates best if your commits are small, fine-grained changes. It makes locating and undoing specific commits much easier.

The stage itself is useful, and as I mentioned above, you're using it whether you like it or not. If you make any commit at all, congratulations, you've staged changes (not files). If you've ever marked something to go into a commit, congratulations, you've staged changes again.

If you're working with git in an optimal manner, staging a few changes and then going back to work is much better than staging everything when you're done and just saying "I added XYZ" in an enormous, difficult to unravel commit. Small changes, on the other hand, let you very easily see where something went wrong in the changes. Testing doesn't cover everything, nor does static analysis and Valgrind, and things go wrong.

Using your method, it's difficult to figure out where something went wrong and quickly undo it if that's all that needs fixing. Using my method, I really just need to use git-revert on whichever commit(s) introduced a bug or regression and it's done.

Also, though I'm of the opinion that you should use the terminal, I can't force people to use it, I can only tell you what I think. My commits look fine regardless of whether they're in a terminal or GUI because they're formatted according to a consistent standard. Yours probably aren't, and I know Joe's aren't.

Your ignorance of the tools you use isn't a good quality. Try to fix it.


This post is from -- http://socoder.net/index.php?topic=2887