> I just don't do 'git commit -a' for the same reason I don't do > 'git commit -m', really. It tends to be habit-forming, and bisect > has saved my arse enough times for me to *want* my changes to be > small and isolated. Debugging a 5-line patch is so much more pleasant > than debugging a 30k-lines one that spans over several different files. 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. Kristian - 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
