Stefan Beller <sbel...@google.com> writes: > On Tue, Jul 18, 2017 at 12:17 PM, Junio C Hamano <gits...@pobox.com> wrote: >> Stefan Beller <sbel...@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.
