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?
