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

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 7, 2009, 00:55 UTC
Message-ID: <7vfxgl46zz.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <vpqiqlh1p8t.fsf@bauges.imag.fr>

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.

Show 6 quoted lines

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