Nicolas Pitre <nico@xxxxxxx> writes: > This argument has its converse. What you should _not_ have to worry > about all the time is whether your index really includes all the changes > you want included in your next commit. That's what we have "git diff" with various output options for; I often do "git diff --stat" or "git diff --name-status" when I know I am about to commit in a dirty working tree. I suspect that I am not getting your point. > And whether wanting to leave local changes in the working directory > without commiting them actually happen more often than wanting to commit > every changes is arguable. I do not think anybody is talking about which happens more often. "screw the index" people do not have to worry about the index during the course of their changes in the working tree toward the next commit, and the only time they need to tell git (which _IS_ a system based on the index, dammit) about what they want to do with the index is at the commit time, and they tell git to "screw the index" by passing "-a" to "git commit". In other words, "-a" at commit time is a magic incantation to allow them to be casual about index manipulation before reaching the point to commit. They do not have to worry about differences between "git rm --force" vs "/bin/rm" nor "git apply" vs "git apply --index"). It might make sense to have a configuration in .git/config that says "user.workingtreeistheking = true". This should obviously affect what "git commit" does by default, but it also should change the behaviour of other commands to suit the "screw the index" workflow better. For example, the configuration should probably make "git diff" (without an explicit --cached nor HEAD) pretend it was asked to show diff between HEAD and the working tree, because the user chose not to care about the index. Not caring about the index is different from consciously keeping the index clean; for example, running "git apply --index" by mistake when he meant to say "git apply" should be tolerated, and Porcelain-ish that is working under workingtreeistheking mode should behave as if the index does not exist. In other words, the index is _not_ a staging area towards the next commit for him; the working tree is. I thought Cogito largely follows that model, so it certainly is possible to do things that way. And I would not mind if the changes are cleanly done and maintainable. I am NOT going to say that I will refuse to maintain the code that implements the workingtreeistheking half of the system, although it is very unlikely that I would ever enable that configuration in my repositories. Would that make people happy? I do not think so. I think it will lead to more confusion to have two majorly different semantics in the same set of tools. - 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