On Mon, Jul 31, 2017 at 1:17 PM, Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> wrote: > On Mon, Jul 31, 2017 at 1:24 AM, brian m. carlson > <sandals@xxxxxxxxxxxxxxxxxxxx> wrote: >> 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? That is my understanding as well. > 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. I think that is just adding more workload without furthering the stated goal which is usually reached with just one hash function. The tests we're talking about here are not trying to test correctness of hashes but some other functionality (correct abbreviation length, collisions in prefix, etc.) that would not change depending on the hash function used, I imagine. For t0000 we want to have multiple versions, one for each hash. > 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...
