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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



From: "Junio C Hamano" <gitster@xxxxxxxxx>
"Philip Oakley" <philipoakley@xxxxxxx> writes:

From: "Junio C Hamano" <gitster@xxxxxxxxx>
Ann T Ropea <bedhanger@xxxxxx> 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.





[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux