On Wed, May 17, 2017 at 8:52 PM, Stefan Beller <sbeller@xxxxxxxxxx> wrote:
> 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.
Yeah I agree git.git should dogfood submodules, and this seemed like a
perfect opportunity for thaht.
As noted later in your mail everything may not be ready, so when I
submit a non-RFC version of this (after upstream pulls my changes,
hopefully), the 2nd and 3rd patches can just be dropped.
> 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.
Ouch. So there's no non-manual way with git-archive to make a tarball
release of a git project using submodules?
> I did follow the SHA1DC discussion just from the sideline,
> how crucial is that library for us?
Since 2.13.0 it's git's default sha1 implementation.
> 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.
Wouldn't we lose the ability to just "pull" the module to see if
upstream changed, i.e. now we'd need to manually munge the URL first.
If so having a fetchurl be a relative URL similar to git-push's
pushurl would solve it wouldn't it? I.e. a project like git could say
"here's my mirrors" different from "here's my upstream".