On 7 May 2018 at 01:17, brian m. carlson <sand...@crustytoothpaste.net> wrote: > Add an SHA1 prerequisite to annotate both of these types of tests and > disable them when we're using a different hash. In the future, we can > create versions of these tests which handle both SHA-1 and NewHash.
Minor nit: s/can/can and should/ > + > +# SHA1 is a test if the hash algorithm in use is SHA-1. This is both for > tests > +# which will not work with other hash algorithms and tests that work but > don't > +# test anything meaningful (e.g. special values which cause short > collisions). > +test_lazy_prereq SHA1 ' > + test $(git hash-object /dev/null) = > e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 > +' So SHA1 means roughly "git hash-object uses SHA-1, so supposedly everything on disk is SHA-1." I could imagine one or two different meanings: "Git was compiled with support for SHA-1 [oids]." Do we actually need more SHA-1-related prereqs, at least long-term, in which case we would want to find a more specific name for this one now? Is this SHA1_STORAGE, or some much better name than that? I am thinking for example about a repo with NewHash that gets pushed to and fetched from a SHA-1 server, see hash-function-transition.txt, goal 1b. We'd want to always test that SHA-1-related functionality in git. (But only until the day when someone defines a prereq such as "SHA1" to be able to test a git that was compiled without any traces of SHA-1 whatsoever.) Martin
