I understand why people like staging and commit without -a, seeing how it's faster and all, but I have a serious problem with this practice that I haven't seen brought up on the list. How do you know what you commit actually works or even compiles? The reason that I almost exclusively use -a with commit is that I want to know that what I just compiled and tested is what I will be committing. I don't want to just commit half the files in my working copy, I want to make sure that the exact state of my project that I just compiled and tested is what gets into version controlled history. git commit -a isn't sloppy to me - eye balling some subset of your working copy and committing that under the assumption that you don't make mistakes and don't need to compile what you commit... that is sloppy.
Agreed. For this reason git-commit without -a, staging, index, ... is not really interesting to me. In CVS and subversion (which has nicer working-copy command line interface IMHO), I simply make a copy of the working copy, revert the non-commitable parts, build, commit the minor changes, and then update the first copy. For larger projects, where this can be slow, I use diff/revert/patch. Small checkins are nice for git-bisect, but if they don't build... Mark - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
