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

2017-06-26 Thread Jonathan Tan
On Sat, 24 Jun 2017 16:25:13 -0700
Junio C Hamano  wrote:

> * jt/unify-object-info (2017-06-21) 8 commits
>  - sha1_file: refactor has_sha1_file_with_flags
>  - sha1_file: do not access pack if unneeded
>  - sha1_file: improve sha1_object_info_extended
>  - sha1_file: refactor read_object
>  - sha1_file: move delta base cache code up
>  - sha1_file: rename LOOKUP_REPLACE_OBJECT
>  - sha1_file: rename LOOKUP_UNKNOWN_OBJECT
>  - sha1_file: teach packed_object_info about typename
> 
>  Code clean-ups.
> 
>  Looked sensible to me.  Any further comments?
>  cf. <20170624124522.p2dnwdah75e4n...@sigill.intra.peff.net>

In a reply that I just sent out [1], I suggested "sha1_file: support
more flags in object info query" to replace "sha1_file: improve
sha1_object_info_extended" (the 6th patch from the bottom). If you are
OK with that commit message title, and if you prefer not to make the
change locally yourself, I can send out a reroll with the updated commit
message title.

[1] 
https://public-inbox.org/git/cagf8dgj8c0choxzo5cpt56225xgbgrjagy8hdast+0-usfw...@mail.gmail.com/


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

2017-06-26 Thread Junio C Hamano
Lars Schneider  writes:

>> On 26 Jun 2017, at 11:44, Ævar Arnfjörð Bjarmason  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.



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

2017-06-26 Thread Lars Schneider

> On 26 Jun 2017, at 11:44, Ævar Arnfjörð Bjarmason  wrote:
> 
> 
> On Mon, Jun 26 2017, Lars Schneider jotted:
> 
>>> On 25 Jun 2017, at 01:25, Junio C Hamano  wrote:
>> 
>>> ...
>> 
>>> * ab/sha1dc (2017-06-07) 2 commits
>>> - sha1collisiondetection: automatically enable when submodule is populated
>>> - sha1dc: optionally use sha1collisiondetection as a submodule
>>> 
>>> The "collission-detecting" implementation of SHA-1 hash we borrowed
>>> from is replaced by directly binding the upstream project as our
>>> submodule.
>>> 
>>> Will keep in 'pu'.
>>> cf. 
>>> 
>>> The only nit I may have is that we may possibly want to turn this
>>> on in .travis.yml on MacOS before we move it forward (otherwise
>>> we'd be shipping bundled one and submodule one without doing any
>>> build on that platform)?  Other than that, the topic seems ready to
>>> be merged down.
>> 
>> What do you mean by "turn this on in .travis.qml on MacOS"?
>> The submodule is already cloned on all platforms on Travis:
>> https://travis-ci.org/git/git/jobs/246965294#L25-L27
>> 
>> However, I think DC_SHA1_SUBMODULE (or even DC_SHA1) is not enabled
>> on any platform right now. Should we enable it on all platforms or
>> add a new build job that enables/tests these flags?
> 
> 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?

- Lars

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

2017-06-26 Thread Ævar Arnfjörð Bjarmason

On Mon, Jun 26 2017, Lars Schneider jotted:

>> On 25 Jun 2017, at 01:25, Junio C Hamano  wrote:
>
>> ...
>
>> * ab/sha1dc (2017-06-07) 2 commits
>> - sha1collisiondetection: automatically enable when submodule is populated
>> - sha1dc: optionally use sha1collisiondetection as a submodule
>>
>> The "collission-detecting" implementation of SHA-1 hash we borrowed
>> from is replaced by directly binding the upstream project as our
>> submodule.
>>
>> Will keep in 'pu'.
>> cf. 
>>
>> The only nit I may have is that we may possibly want to turn this
>> on in .travis.yml on MacOS before we move it forward (otherwise
>> we'd be shipping bundled one and submodule one without doing any
>> build on that platform)?  Other than that, the topic seems ready to
>> be merged down.
>
> What do you mean by "turn this on in .travis.qml on MacOS"?
> The submodule is already cloned on all platforms on Travis:
> https://travis-ci.org/git/git/jobs/246965294#L25-L27
>
> However, I think DC_SHA1_SUBMODULE (or even DC_SHA1) is not enabled
> on any platform right now. Should we enable it on all platforms or
> add a new build job that enables/tests these flags?

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.


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

2017-06-26 Thread Lars Schneider

> On 25 Jun 2017, at 01:25, Junio C Hamano  wrote:

> ...

> * ab/sha1dc (2017-06-07) 2 commits
> - sha1collisiondetection: automatically enable when submodule is populated
> - sha1dc: optionally use sha1collisiondetection as a submodule
> 
> The "collission-detecting" implementation of SHA-1 hash we borrowed
> from is replaced by directly binding the upstream project as our
> submodule.
> 
> Will keep in 'pu'.
> cf. 
> 
> The only nit I may have is that we may possibly want to turn this
> on in .travis.yml on MacOS before we move it forward (otherwise
> we'd be shipping bundled one and submodule one without doing any
> build on that platform)?  Other than that, the topic seems ready to
> be merged down.

What do you mean by "turn this on in .travis.qml on MacOS"? 
The submodule is already cloned on all platforms on Travis: 
https://travis-ci.org/git/git/jobs/246965294#L25-L27

However, I think DC_SHA1_SUBMODULE (or even DC_SHA1) is not enabled 
on any platform right now. Should we enable it on all platforms or 
add a new build job that enables/tests these flags?

- Lars