Re: [PATCH/RFC 0/3] Use sha1collisiondetection as a submodule

[Brandon Williams <bmwill@google.com>]

On 05/17, Stefan Beller wrote:
> 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!

> 
> 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