Re: [PATCH 01/28] t/test-lib: add an SHA1 prerequisite

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: May 7, 2018, 23:30 UTC
Message-ID: <20180507233000.GI953644@genre.crustytoothpaste.net>
In-Reply-To: <CAN0heSqk0siv4y5BGz2+sLhAyNG=TEZmgucKoCDGyx2i8_O+tQ@mail.gmail.com>

On Mon, May 07, 2018 at 12:10:39PM +0200, Martin Ågren wrote:

Show 6 quoted lines

> On 7 May 2018 at 01:17, brian m. carlson <sandals@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/

I agree with that sentiment.  I can change that.

Show 11 quoted lines

> > +
> > +# 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]."

Currently it means that, yes. It may specialize to mean, "git emits SHA-1 output, regardless of the format on disk." See cases 1 and 2 below.

> 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?

We may.  The transition plan anticipates several states:

1. Store data in NewHash, but input and output are SHA-1.
2. Store data in NewHash; output is SHA-1; input can be either.
3. Store data and output in NewHash; input can be either.
4. All NewHash.

At this point, I'm working on getting the tests to handle case 4, as that's actually the easiest to fix (because if things are wrong, the code tends to segfault). Case 1 will be next, in which case, we may need SHA1_STORAGE or such.

I plan to make the SHA1 prerequisite go away or at least be far less used in a few releases. Once we know what NewHash is going to be, it's pretty easy to write tooling and translation tables that do the conversion for most tests, and a test helper can simply emit the right output for whichever algorithm we're using in that situation, whether that's the on-disk algorithm, the input algorithm, or the output algorithm.

Show 6 quoted lines

> 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.)

I anticipate that by the time we get to that point, the SHA1 prerequisite will be long gone and can be reused for that purpose, should we need it.

-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204