From: Junio C Hamano Date: Tue, 18 Jul 2017 19:38:21 GMT Subject: Re: [PATCH] t8008: rely on rev-parse'd HEAD instead of sha1 value Message-ID: In-Reply-To: Stefan Beller writes: > On Tue, Jul 18, 2017 at 12:17 PM, Junio C Hamano wrote: >> Stefan Beller 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.