Re: [PATCH] Re-re-re-fix common tail optimization

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 16, 2007, 22:28 UTC
Message-ID: <7vodcqi8aq.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <7vtzmii8io.fsf@gitster.siamese.dyndns.org>

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

Show 16 quoted lines

>>> +test_expect_success 'diff -U0' '
>>> +
>>> +	git diff -U0 | sed -e "/^index/d" -e "s/$z2047/Z/g" >actual &&
>>> +	diff -u expect actual
>>
>> Aren't we using "git diff" for the second diff there nowadays?
>
> Some people seem to think that is a good idea, but I generally do not
> like using "git diff" between expect and actual (both untracked) inside
> tests.  The last "diff" is about validating what git does and using "git
> diff" there would make the test meaningless when "git diff" itself is
> broken.
>
> This is especially so because comparison between untracked files is a
> bolted-on afterthought and I am least confident about among the
> codepaths in the whole "git diff" (it is not even my nor Linus's code).

Side note. The "confidence" I am talking about the above is not about the correct-working of the current code. It seems to work fine.

It is about the fact it was bolted on rather than designed in from the beginning---it is much likely to subtly break than other parts that are much more integrated when you change seemingly unrelated thing like git-dir discovery and rename detection.

IOW, the confidence is about the fixability/maintainability when somebody breaks it.