Re: [PATCH 00/10] Hash-independent tests (part 1)

From: Eric Sunshine <sunshine@sunshineco.com>
Date: Mar 26, 2018, 02:10 UTC
Message-ID: <CAPig+cR==SNfGdhwqPdvW75fUxXg-VSQ5Tz_OR7Sy_c0L94axQ@mail.gmail.com>
In-Reply-To: <20180325192055.841459-1-sandals@crustytoothpaste.net>

On Sun, Mar 25, 2018 at 3:20 PM, brian m. carlson <sandals@crustytoothpaste.net> wrote:

Show 13 quoted lines

> This is a series to make our tests hash-independent.  Many tests have
> hard-coded SHA-1 values in them, and it would be valuable to express
> these items in a hash-independent way for our hash transitions.
>
> The approach in this series relies on only three components for hash
> independence: git rev-parse, git hash-object, and EMPTY_BLOB and
> EMPTY_TREE.  Because many of our shell scripts and test components
> already rely on the first two, this seems like a safe assumption.
>
> For the same reason, this series avoids modifying tests that test these
> components or their expected SHA-1 values.  I expect that when we add
> another hash function, we'll copy these tests to expose both SHA-1 and
> NewHash versions.

What's the plan for oddball cases such as 66ae9a57b8 (t3404: rebase -i: demonstrate short SHA-1 collision, 2013-08-23) which depend implicitly upon SHA-1 without actually hardcoding any hashes? The test added by 66ae9a57b8, for instance, won't start failing in the face of NewHash, but it also won't be testing anything meaningful.

Should such tests be dropped altogether? Should they be marked with a 'SHA1' predicate or be annotated with a comment as being SHA-1-specific? Something else?