From: Junio C Hamano <gitster@pobox.com>
Date: Mon, 06 Apr 2009 05:17:26 GMT
Subject: Re: [RFC/PATCH 0/2] New 'stage' command
Message-ID: <7v63hie4yh.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <20090406032457.GA14758@gmail.com>

David Aguilar <davvid@gmail.com> writes:

> On  0, Sverre Rabbelier <srabbelier@gmail.com> wrote:
>> Heya,
>> 
>> On Mon, Apr 6, 2009 at 01:17, Markus Heidelberg
>> <markus.heidelberg@web.de> wrote:
>> > Felipe Contreras, 06.04.2009:
>> >> But actually, "git diff --cached" is a
>> >> different action; you can't do "git diff --cached HEAD^.." for
>> >> example.
>> >
>> > And I neither could I do "git stage diff HEAD^.."
>> 
>> I rest my case ;). That's the whole point Felipe is trying to make here.
>> $ git diff --cached
>> $ git diff HEAD^..
>> 
>> That's two different modes of operation with the only difference being
>> a switch ('--cached'), which changes what is, and what is not valid
>> after that.
>> 
>> Whereas with
>> $ git stage diff
>> 
>> There is no confusion that 'HEAD^..' is not a valid argument, as there
>> is no command in 'git stage diff' to which it _is_ a valid argument.
>
> Hello
>
> Here's an interesting email from a while back:
>
> http://kerneltrap.org/mailarchive/git/2008/10/29/3857134
>
> The above mentions the following suggestion:
>
>     git diff STAGE WORKTREE   (like "git diff" today)
>     git diff HEAD WORKTREE    (like "git diff HEAD" today)
>     git diff WORKTREE HEAD    (like "git diff -R HEAD" today)
>     git diff HEAD STAGE       (like "git diff --cached" today)
>     git diff commit STAGE     (like "git diff --cached commit" today)
>
>
> From a consistency and usability perspective, the above
> example seems very appealing because:
>
> a) it does not introduce any new commands, and
>
> b) it is consistent with the way git-diff's command-line
>    interface works today.
>
> All we'd have to do is teach git-diff to special-case
> 'STAGE' and 'WORKTREE'.  Now, whether we'd want to do
> that is a completely different discussion, but I figured I'd
> throw the old thread out there.

How would you express operations the current --index option does in such a
scheme?  Yet another WORKTREEANDTHEINDEX token?