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

From: David Kågedal <davidk@lysator.liu.se>
Date: Apr 6, 2009, 13:20 UTC
Message-ID: <871vs5kjfw.fsf@krank.kagedal.org>
In-Reply-To: <7v63hie4yh.fsf@gitster.siamese.dyndns.org>

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

Show 5 quoted lines

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

Show 26 quoted lines

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