Re: [RFC/PATCH 0/2] New 'stage' command

Matthieu Moy [off-list ref] 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.

quoted

   - 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.