Re: [PATCH/RFC 0/3] Use sha1collisiondetection as a submodule
- Date: Wed, 17 May 2017 17:11:52 -0700
- From: Brandon Williams <bmwill@xxxxxxxxxx>
- Subject: Re: [PATCH/RFC 0/3] Use sha1collisiondetection as a submodule
On 05/17, Stefan Beller 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.
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!
> 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,