The following message is a courtesy copy of an article
that has been posted to gmane.comp.version-control.git as well.

Junio C Hamano <gitster@pobox.com> writes:

quoted text
> David Aguilar <davvid@gmail.com> writes:
>
>> Hello
>>
>> Here's an interesting email from a while back:

Thanks, I would have brought it back up myself if you hadn't.

quoted text
>> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html