Re: [PATCH/RFC 0/3] Use sha1collisiondetection as a submodule
- From
- Brandon Williams <bmwill@google.com>
- Date
- May 18, 2017, 00:11 UTC
- Message-ID
- <20170518001152.GE185461@google.com>
- In-Reply-To
- <CAGZ79kZC98CxA69QjmX2s_SU6z1CSgKgwZeqvwiMRAQc6+S3xg@mail.gmail.com>
On 05/17, Stefan Beller wrote:
Show 37 quoted lines
> On Wed, May 17, 2017 at 4:38 AM, Ævar Arnfjörð Bjarmason
> <avarab@gmail.com> wrote:
> > On Wed, May 17, 2017 at 9:09 AM, Junio C Hamano <gitster@pobox.com> wrote:
> >> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> >>
> >>> On Wed, May 17, 2017 at 7:39 AM, Junio C Hamano <gitster@pobox.com> wrote:
> >>>> From: Marc Stevens <marc@marc-stevens.nl>
> >>>>
> >>>> 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.Haha, I wish I had your enthusiasm for this. That is a good argument for us to include them in git.git, but I still feel apprehensive. There is still so much to do in submodule land! We'll make them great though!
Show 28 quoted lines
> > 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
-- Brandon Williams