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