Re: What's cooking in git.git (Jun 2017, #07; Sat, 24)

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 26, 2017, 15:49 UTC
Message-ID: <xmqq8tke7nrg.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <D0D3C60B-84E3-431B-A600-546ABA1D1209@gmail.com>

Lars Schneider <larsxschneider@gmail.com> writes:

Show 18 quoted lines

>> On 26 Jun 2017, at 11:44, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
>> 
>> If we're cloning the submodule, which from this output, and AFAIK in
>> general happens with all Travis builds, but correct me if I'm wrong
>> we'll set DC_SHA1_SUBMODULE=auto due to this bit in the Makefile:
>> 
>>    ifeq ($(wildcard sha1collisiondetection/lib/sha1.h),sha1collisiondetection/lib/sha1.h)
>>    DC_SHA1_SUBMODULE = auto
>>    endif
>> 
>> So if (and I think this is the case) Travis just does a clone with
>> --recurse-submodules then this is already being CI'd.
>
> Do you see some other way to check if this is part of the build?
> Would it make sense to add this info to "git --version --build-options"?
>
> I am not familiar with the SHA1 machinery... but does it work on macOS
> even though we generally use APPLE_COMMON_CRYPTO?

I thought that we allowed "Use apple-common-crypto for the real openssl thing (like curl and imaps) but use the hash function from this other thing (like block-sha/)" and was hoping that we can test sha1dc/ and/or sha1collisiondetection/ with that mechanism.

OTOH, if the binary packaged one on MacOS uses everything from apple-common-crypto, then not testing with that gives us a larger coverage gap, so unless we add a _new_ target that uses sha1dc/ on MacOS, it may not worth be worrying about.