David Aguilar [off-list ref] writes:
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.
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?
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
Junio C Hamano [off-list ref] writes:
David Aguilar [off-list ref] writes:
quoted
Hello
Here's an interesting email from a while back:
Thanks, I would have brought it back up myself if you hadn't.
quoted
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?
What do you mean? This was a suggestion for how git diff should
work. I fail to see how you would need a WORKTREEANDTHEINDEX there.
I think this is a basic usability issue for a high-level porcelain
command such as diff. Having the command syntax "git diff <something>
<somethingelse>" makes sure you never wonder what you are
diffing. "git diff --cached" makes me wonder what the index is diffed
against every time I see it.
We wouldn't have to use the "STAGE" or "WORKTREE" names, of course. It
doesn't have to look like refspecs even. The last example already has
a syntax that matches the suggestion:
git diff --cached <commit>
So, extrapolating this to "git diff --worktree --cached" would mean
what "git diff -R" means today etc.
The obvious objection is that "git diff --cached <foo>" would mean the
inverse of "git diff <foo> --cached", but maybe that isn't so
unexpected by the user after all?
--
David Kågedal