Re: [PATCH] t8008: rely on rev-parse'd HEAD instead of sha1 value

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 18, 2017, 19:38 UTC
Message-ID: <xmqqk235o7rm.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CAGZ79kbTQ=eSoDCRFTt_B3kjDbWZDkcPwc3fMvhd8dEKPWr-8A@mail.gmail.com>

Stefan Beller <sbeller@google.com> writes:

Show 17 quoted lines

> On Tue, Jul 18, 2017 at 12:17 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Stefan Beller <sbeller@google.com> writes:
>>
>>> Remove hard coded sha1 values, obtain the values using 'git rev-parse HEAD'
>>> which should be future proof regardless of the hash function used.
>>
>> Don't hardcoded lengths of the hashes defeat this future-proofing
>> effort, though?  It shouldn't be too hard to do the equivalent of
>> the auto computation of abbreviation in this script, which would be
>> true future-proofing, I guess.
>
> It depends on the definition of future proofing.
> My definition here only included the change of the hash function,
> not the change of display length in git-blame for a small artificial repo
> with 2 commits . These seem to be unrelated, so in case we'd change
> the length of the abbreviated displayed hash, we'd still want to have
> a test to tell us?

The thing is that depending on how these 2 commits hash and share prefixes, the length needed to disambiguate changes.