Re: [PATCH v3 5/5] Testing: provide tests requiring them with ellipses after SHA-1 values
- From
Philip Oakley <philipoakley@iee.org>
- Date
- Nov 22, 2017, 23:41 UTC
- Message-ID
- <FDCFD8EC7A754412A6369F03E91926C5@PhilipOakley>
- In-Reply-To
- <xmqqo9nuuadm.fsf@gitster.mtv.corp.google.com>
From: "Junio C Hamano" <gitster@pobox.com>
Show 24 quoted lines
> "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.
Show 6 quoted lines
> > 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.
Show 11 quoted lines
> >> 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.