From: Ævar Arnfjörð Bjarmason <firstname.lastname@example.org> To: Stefan Beller <email@example.com> Cc: "firstname.lastname@example.org" <email@example.com>, Junio C Hamano <firstname.lastname@example.org>, Marc Stevens <email@example.com>, Michael Kebe <firstname.lastname@example.org>, Jeff King <email@example.com> Subject: Re: [PATCH/RFC 0/3] Use sha1collisiondetection as a submodule Date: Wed, 17 May 2017 21:45:16 +0200 Message-ID: <CACBZZX6Gad32eZX6BTamNK016wu3HHLdYDB6JkUPNv=+mB3PKg@mail.gmail.com> (raw) In-Reply-To: <CAGZ79kZC98CxA69QjmX2s_SU6z1CSgKgwZeqvwiMRAQc6+S3xg@mail.gmail.com> On Wed, May 17, 2017 at 8:52 PM, Stefan Beller <firstname.lastname@example.org> wrote: > On Wed, May 17, 2017 at 4:38 AM, Ævar Arnfjörð Bjarmason > <email@example.com> wrote: >> On Wed, May 17, 2017 at 9:09 AM, Junio C Hamano <firstname.lastname@example.org> wrote: >>> Ævar Arnfjörð Bjarmason <email@example.com> writes: >>> >>>> On Wed, May 17, 2017 at 7:39 AM, Junio C Hamano <firstname.lastname@example.org> wrote: >>>>> From: Marc Stevens <email@example.com> >>>>> >>>>> 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".
next prev parent reply index Thread overview: 17+ messages in thread (expand / mbox.gz / Atom feed / [top]) 2017-05-15 12:49 Git 2.13.0 segfaults on Solaris SPARC due to DC_SHA1=YesPlease being on by default Ævar Arnfjörð Bjarmason 2017-05-15 13:58 ` Marc Stevens 2017-05-15 14:13 ` Ævar Arnfjörð Bjarmason 2017-05-15 22:09 ` Jeff King 2017-06-01 14:03 ` demerphq [not found] ` <CAKKM46vwM9pxyMxTc4jA0z_8vGKdDGCGg9ziKkFAsqr5ULYJxA@mail.gmail.com> [not found] ` <firstname.lastname@example.org> 2017-05-16 5:43 ` Michael Kebe 2017-05-17 5:39 ` [PATCH] sha1dc: fix issues with a big endian platform Junio C Hamano 2017-05-17 6:30 ` Ævar Arnfjörð Bjarmason 2017-05-17 7:09 ` Junio C Hamano 2017-05-17 11:38 ` [PATCH/RFC 0/3] Use sha1collisiondetection as a submodule Ævar Arnfjörð Bjarmason 2017-05-17 18:52 ` Stefan Beller 2017-05-17 19:45 ` Ævar Arnfjörð Bjarmason [this message] 2017-05-17 19:57 ` Stefan Beller 2017-05-18 0:11 ` Brandon Williams 2017-05-17 11:38 ` [PATCH/RFC 1/3] sha1dc: update from my fork of upstream Ævar Arnfjörð Bjarmason 2017-05-17 11:38 ` [PATCH/RFC 2/3] sha1dc: use sha1collisiondetection as a submodule Ævar Arnfjörð Bjarmason 2017-05-17 15:26 ` [PATCH] sha1dc: fix issues with a big endian platform Johannes Schindelin
Reply instructions: You may reply publically to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: http://vger.kernel.org/majordomo-info.html * Reply to all the recipients using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CACBZZX6Gad32eZX6BTamNK016wu3HHLdYDB6JkUPNv=+mB3PKg@mail.gmail.com' \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
firstname.lastname@example.org mailing list mirror (one of many) Archives are clonable: git clone --mirror https://public-inbox.org/git git clone --mirror http://ou63pmih66umazou.onion/git git clone --mirror http://czquwvybam4bgbro.onion/git git clone --mirror http://hjrcffqmbrq6wope.onion/git Newsgroups are available over NNTP: nntp://news.public-inbox.org/inbox.comp.version-control.git nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git nntp://news.gmane.org/gmane.comp.version-control.git note: .onion URLs require Tor: https://www.torproject.org/ or Tor2web: https://www.tor2web.org/ AGPL code for this site: git clone https://public-inbox.org/ public-inbox