Re: [PATCH] t8008: rely on rev-parse'd HEAD instead of sha1 value
- From
Stefan Beller <sbeller@google.com>
- Date
- Jul 18, 2017, 19:22 UTC
- Message-ID
- <CAGZ79kbTQ=eSoDCRFTt_B3kjDbWZDkcPwc3fMvhd8dEKPWr-8A@mail.gmail.com>
- In-Reply-To
- <xmqqwp75o8qi.fsf@gitster.mtv.corp.google.com>
On Tue, Jul 18, 2017 at 12:17 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 9 quoted lines
> 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?