Carl Worth <cworth@xxxxxxxxxx> writes: > I think what I'm asking for is a much more mild change. The "keep the > index clean" behavior exists almost everywhere already, (the few > exceptions are things like "git cherry-pick -n", and the notable > exception of a conflicted merge). So I don't think supporting "commit > -a by default" means we have to introduce a large conceptual change. We seem to be agreeing (and Linus seems to, too, in a thread next door) that it is a good thing that git keeps index clean unless you explicitly ask it to. We also seem to be agreeing that people with more involved needs can deliberately make index different from HEAD, way before issuing "git commit", and that they can commit even when "git diff" gives nonempty differences, and these are good things. Are we on the same page? Now what does it mean to make "commit" silently update the index with all the changes in the working tree without being told? Unless you are introducing "working tree is the king" mode to git to make everything ignore the index's "contents" part (in other words, the index is used as the CVS/Entries file, nothing more, under that mode of operation), I think you just introduced an inconsistency at the place where the difference matters most. I do not agree what you are asking is a "mild change" at all, and I said it already that it goes against the mental model of how git tools work. Earlier, the world model was "you build it in the index and you make a commit of what is in the index; there is a last-minute index operation you can do by passing paths to commit and as a short-hand there is -a as well [*1*]". Now you made the world model "it does not matter what you have in the index before issuing git-commit; if you want to preserve what you built in the index, you have to do something non-default". That WOULD solicit more newbie confusion. "If it does not matter at the end unless you do something special, why bother doing it at all?" would be the question you would face. Earlier on the "UI warts" thread, people said that the users do not form the mental model of how the toolset works by reading the tool's documentation but by trying things out, and I think that is a valid observation. We should not be sending a wrong message by introducing inconsistencies like that. The tool's UI should naturally reflect what world model it is based on, and like it or not, the world model of git includes the index. The way to explain "-a" to new users should not be "you can _ignore_ index as long as you use -a". I do not think denying the index buys the new users anything. Rather, "building your next commit incrementally in the index is the workflow git is designed to support, but you are not required to do that _incrementally_. Until you encounter a complex situation such as resolving a large conflicting merge, doing that incrementally does not buy you anything as long as you work in a clean working tree. Instead, you can tell git what you want to commit when you run 'git-commit' by giving paths or directory names, or if you want to commit everything in the working tree, then you can also say '-a'". I am all for rewording the cryptic "use update-index to update" message with "use 'commit -a' to commit all of them" or somesuch. That does NOT break the mental model. Another thing that we need to be aware of is that new users won't be "newbies" forever, and the tool should not be optimized for the first few pages of the tutorial. You and Nico say "experienced people can always alias UI warts away", but I think that is a wrong attitude. Users with experience, long after this discussion is forgotten, would complain "other tools help us build the next commit in the index, but git-commit by default discards the distinction between what were marked for commit and what were not, unless explicitly told not to. Why does it do -a by default, and why should I forced to alias that stupid default away?" [Footnote] *1* In retrospect, making "commit -o" the default was a very bad change; I got tired of repeating myself in that discussion and applied that change, but it was probably a mistake. - 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