On Wed, May 17, 2017 at 4:38 AM, Ævar Arnfjörð Bjarmason
<avarab@xxxxxxxxx> wrote:
> On Wed, May 17, 2017 at 9:09 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
>> Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes:
>>
>>> On Wed, May 17, 2017 at 7:39 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
>>>> From: Marc Stevens <marc@xxxxxxxxxxxxxxx>
>>>>
>>>> Some big-endian platforms define _BIG_ENDIAN, which the test at the
>>>> beginning of file has missed. Also, when the input is not aligned,
>>>> some platforms trigger SIGBUS.
>>>>
>>>> This change corresponds to 33a694a9 ("Fix issues with a big endian
>>>> platform", 2017-05-15) in the history of the upstream repository
>>>> https://github.com/cr-marcstevens/sha1collisiondetection
>>>
>>> Then why not just update sha1dc from upstream instead of
>>> cherry-picking one patch from them?
>>
>> See the original message upthread. I did the cherry-pick simply
>> because that was what Marc instructed the patch recipient to do ;-).
>
> Since that patch is now in Marc's upstream code we can just update to
> that.
>
> While we're at it let's see if Marc will take a patch so that we can
> use his code as-is with some Makefile trickery of our own, instead of
> having to solve merge conflicts each time we update from him. I'll
> submit a pull request for that shortly.
>
> And since if and when that pull request gets accepted we're at the
> point of being able to use the upstream code as-is & don't need to
> locally modify it, we can just use a submodule to track it.
As someone who works on submodules: YAY! This sounds
wonderful in the sense that more git developers experience the
sharp edges (if any) of submodules and would fix them.
With the reset work on submodules (checkout, reset,
ls-files, grep) and more in the works (better push/pull)
we may be close to prime time.
However we do distribute tarballs (well, Junio does),
which is not yet supported to include submodules.
I did follow the SHA1DC discussion just from the sideline,
how crucial is that library for us?
Also now that we discuss having submodules:
Would we just point the submodule URL to github\
and call it a day?
We could make a friendly fork of it and put it next to all the repositories
of https://git-blame.blogspot.com/p/git-public-repositories.html
and then use relative URLs in the .gitmodules file.
On a tangent, in an off-list discussion we discussed having
the git-annex tests as an optional submodule instead of an
"external" test, but in conclusion we considered that idea not
ideal to implement (because our tests are like contracts, we should
actually write our own tests and not rely on downstream to write
tests for us)
looking forward for a discussion here,
Stefan