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

[Junio C Hamano <gitster@pobox.com>]

Matthieu Moy <Matthieu.Moy@imag.fr> 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.