Re: [PATCH] diff: support --root --cached combination

Jonathan Nieder [off-list ref] writes:

Using --root as the backward-compatibility option seems like
an abuse of language, anyway.  "git diff --cached" has two
meanings:

 1. show changes to be committed

    1b. show what git show --format=" " would say after a commit

 2. show differences between the index and the commit named by the
    (implicit) HEAD argument

With interpretation (1b), --root should be respected, and the output
should be empty (!), not an error, when "[log] showroot" is false.

With interpretation (2), --root should not be respected, and an
attempt to diff --cached in an unborn branch should be an error.

(1a) and (1b) are the only useful interpretations.  So for simplicity,
would it make sense to drop the "if ()" for --root and make

quoted

+test_expect_success 'diff --cached' '
+	test_must_fail git diff --cached
+'

fail?

I don't see 1a up above, but I agree.

Let's explain the patch this way (yes, I am writing a proposed commit log
message Duy should have written):

    "git diff --cached" (without revision) used to mean "git diff --cached
    HEAD" (i.e. the user was too lazy to type HEAD).  This "correctly"
    failed when there was no commit yet.  But was that correctness useful?

    This patch changes the definition of what particular command means.
    It is a request to show what _would_ be committed without further "git
    add".  The internal implementation is still the same "git diff
    --cached HEAD" when HEAD exists, but when there is no commit yet, it
    compares the index with an empty tree object to achieve the desired
    result.

Unlike "diff-index --cached HEAD" that must fail when HEAD does not name a
valid rev, we do not have to be so strict in "git diff" Porcelain,
especially when the end user does not even explicitly say HEAD.

To put it in another way, we should strive to define the behaviour of the
plumbing precisely in terms of the mechanism and machinery (e.g. if you
ask for an operation between a tree and the index, and if you incorrectly
specified the tree, you _should_ get an error, instead of a result that
somebody randomly chose, saying "we thought it would be more useful for
you this way").  But we should try to define the behaviour of the
Porcelain commands in terms of the use case and the workflow we try to
encourage and support.