git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 2/2] t6500: mark tests as SHA1 reliant

From
Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date
Jul 31, 2017, 20:17 UTC
Message-ID
<CACBZZX43JFOAOTffWVEMT1fPuzAiZnYi4JoE55QWquZ4kLA2Hg@mail.gmail.com>
In-Reply-To
<20170730232427.vrqrrhlsap55ax7t@genre.crustytoothpaste.net>

On Mon, Jul 31, 2017 at 1:24 AM, brian m. carlson <sandals@crustytoothpaste.net> wrote:

Show 20 quoted lines
> On Sun, Jul 30, 2017 at 11:00:19PM +0000, brian m. carlson wrote:
>> Yes, basically, but a bit more generally.  There will always be cases in
>> which we need to specify an object ID or an arbitrary string and the
>> behavior will need to vary based on the hash.  That can be something
>> like, in this case, the two blob contents that would have the similar
>> prefix.
>>
>> So in this case, we pass the helper the string "263 410" and get back a
>> value for either the hacked SHA-1 hash or the SHA-256 or whatever we're
>> using.
>
> I realize this was worded poorly.  So for my example, in this case, we'd
> do:
>
> test-helper-hash-string "263 410"
>
> For SHA-1, we'd get "263 410".  For SHA-256, we'd get "313 481" (which,
> as SHA-256 blobs, both start with "17" in their hex representation).
> Presumably we'd read some environment variable to determine the proper
> value.

I've been mostly out of the loop on this hash transition plan, but don't we expect to be compiling a git that knows about both SHA-1 and whatever the $newhash is? If so it seems better to just test all N hashes we have:

    test_expect_success_hash $desc_description '
        hash_value=$(test-helper-hash-string $CURRENT_HASH)
        ....
    '
Then test_expect_success_hash would run N times for the N hashes we have.

This would obviously be slightly more hassle to write & convert, but I think it would be worth it, particularly with something like Travis where we can test all hashes, instead of being in some mode where we fragment on all of hashes/gettext poison and whatever other compilation option we have that really requires compiling a new git version...

Previous: brian m. carlsonNext: Stefan Beller
Message 12 of 15 in “How to migrate our test infrastructure away from sha1”
  1. 0/2 How to migrate our test infrastructure away from sha1Stefan Beller, Jul 28, 2017
  2. 1/2 alter hash function: expose test dependencies on sha1Stefan Beller, Jul 28, 2017
  3. Junio C HamanoJul 28, 2017
  4. 2/2 t6500: mark tests as SHA1 reliantStefan Beller, Jul 28, 2017
  5. Junio C HamanoJul 28, 2017
  6. Stefan BellerJul 28, 2017
  7. Junio C HamanoJul 28, 2017
  8. brian m. carlsonJul 29, 2017
  9. Junio C HamanoJul 30, 2017
  10. brian m. carlsonJul 30, 2017
  11. brian m. carlsonJul 30, 2017
  12. Ævar Arnfjörð BjarmasonJul 31, 2017
  13. Stefan BellerJul 31, 2017
  14. Stefan BellerJul 31, 2017
  15. brian m. carlsonJul 31, 2017

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.