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

On  0, Junio C Hamano [off-list ref] wrote:

David Aguilar [off-list ref] writes:

quoted

On  0, Sverre Rabbelier [off-list ref] wrote:

quoted

Heya,

On Mon, Apr 6, 2009 at 01:17, Markus Heidelberg
[off-list ref] wrote:

quoted

Felipe Contreras, 06.04.2009:

quoted

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.

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

Is it a trick question?
git-diff doesn't have an --index option, only --staged.

Ah, I know the answer:

http://kerneltrap.org/mailarchive/git/2008/11/12/4072144
http://kerneltrap.org/mailarchive/git/2008/11/12/4067114
http://kerneltrap.org/mailarchive/git/2008/11/2/3896104

I did say it *seemed* appealing, not that it actually was ;)


Alrighty.. my only purpose was to bring up the old thread
since I think many ideas were fleshed out back when
'git diff --staged' was introduced.

How useful it is in the context of this discussion about a
new 'stage' command is questionable, so I'll shut up now =)

-- 

	David