Re: [PATCH v3 5/5] Testing: provide tests requiring them with ellipses after SHA-1 values

["Philip Oakley" <philipoakley@iee.org>]

From: "Junio C Hamano" <gitster@pobox.com>
> "Philip Oakley" <philipoakley@iee.org> writes:
>
>> From: "Junio C Hamano" <gitster@pobox.com>
>>> Ann T Ropea <bedhanger@gmx.de> writes:
>>>
>>>> *1* We are being overly generous in t4013-diff-various.sh because we do
>>>> not want to destroy/take apart the here-document.  Given that all this 
>>>> a
>>>> temporary measure, we should get away with it.
>>
>> So, the need to reformat the test for the future post-deprecation
>> period is being deferred to the time that the PRINT_SHA1_ELLIPSIS env
>> variable, and all ellipis, is removed - is that the case? Maybe it
>> just needs saying plainly.
>
> And if we say it that way, it is clear that with this series, we are
> shipping a new feature with a test that does not protect the output
> format we claim to be the improved and preferred one.  That sounds
> quite bad.
>
> Having said that, I have already queued this to 'pu' and I do not
> terribly mind to merge it down to 'next', leaving the test updates
> to cover the new output format as well as the backward compatible
> one at the same time for a later follow-up patch.

I'd agree. I just wanted to ensure that I had the right understanding.
>
> I'd however hate it if I have to carry the topic in the current
> shape in 'next' forever, waiting for such an update to come, that
> may never materialize, and be forced to do it myself without being
> explicitly asked by (and thanked for) anybody, especially because
> this is not exactly my itch X-<.

True.
>
>> Or is the env variable being retained as a fallback 'forever'? I'm
>> half guessing that it may tend toward the latter as it's an easier
>> backward compatibility decision.
>
> We do not know until this change is released to the wild, at which
> time we will hear noises about the lack of expected ellipses their
> (poorly written) scripts rely on and tell them to set the workaround
> environment variable.  We may not hear from such people at all, in
> which case we may be able to remove it within a year or so, but it
> is too early to tell.

I was wondering if there should be a small documentation change for the env 
variable and states that it is a temporary measure for short term 
compatibility. Though I'm not sure where the 'right' place would be for it.