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

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 29, 2010, 17:06 UTC
Message-ID: <7vhbg56i9s.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20101029101959.GA27662@burratino>

Jonathan Nieder <jrnieder@gmail.com> writes:

Show 25 quoted lines

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