Matthieu Moy <Matthieu.Moy@xxxxxxx> writes: > But that doesn't apply to "git diff". Both "git diff" and "git diff > --cached" work with the index. It is so often used against HEAD that it is the default for --cached mode. If it confuses your students, do not teach them "git diff --cached" without teaching "git diff --cached HEAD" first. > ... which is everything but intuitive. The option name doesn't tell > the user what the command is doing. Surely, I already said that --cached vs --index are not the best words, didn't I? But the point was that introducing STAGE and other "ref-looking tokens" not only does not help the situation at all, but makes it worse. > I can understand the historical reasons, but I think finding a way to > get rid of this historical terminology mess should be encourraged. No, you should aim higher, if you are trying to change things. Find a way to convey the concepts better, and come up with a way (i.e. set of options---as I already explained why ref looking tokens is inferiour than explicit options) that does not break the backward compatibility, and help new people learn. I am not interested in the "ref-looking tokens" because they fail the latter test. >> - for all commands, working with work tree is the default, so there is >> no --work-tree option (we could add one, if you really want). > > Except "git checkout", which takes the index by default, and > a commit if specified. It makes sense since checking-out from the > working tree doesn't make sense,... You say "except X" but you need to qualify "but that default makes sense for X". I'd say that is true for all X---so you are saying the default is sensible, which is good. > Except "git ls-files", too.... It is a plumbing that only works with the index. What's your problem? > See, you complain about special cases with the proposal, but the > current UI _has_ tons of special cases like this. The two example you quoted above are neither tons nor special cases. And I am not saying that "ref-looking tokens are bad because there are special cases" anyway. -- 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