Kristian Høgsberg <krh@xxxxxxxxxx> writes: > I understand why people like staging and commit without -a, seeing how > it's faster and all, Actually, commit without -a is not much faster, since it runs "status" internally, to show it to the user when launching the editor. So, it still checks for changes in the working tree. > 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? That's a general problem with partial commits, and that's why I personnaly don't like partial commits in general ($scm commit file1 file2 has the same problem, \forall $scm). To me, the right approach to partial commit is to stash the unwanted changes, test, commit, and unstash. (side note: it would be cool to have a "git stash --unstaged" command, to put the unstaged changes aside, and match the tree to the index. A good approximation for that is: $ git stash # put all aside $ git reset --mixed stash^2 # get back what the index used to be $ git add -u # and put it back into the index. ) *But*, the cool thing with git is that you can view rather easily not only what you're about to commit (git diff --cached), but also what you're about _not_ to commit (git diff). So, if the unstaged changes are trivial enough, it can be OK (for example, Linus changes the linux version in a Makefile a few commits before the release, and doesn't add it to the index, to keep it as a reminder). But I agree with your that splitting a huge patch into smaller ones using just the index is bad practice, except if you intend to come back to each commit and test it later. -- Matthieu - 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
