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