From: Stefan Beller <firstname.lastname@example.org> To: Ævar Arnfjörð Bjarmason <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 12:57:18 -0700 Message-ID: <CAGZ79kZXgjC84vsXtvPu_=ApJOkAwUjV1BCS2iETowF-sSrrvw@mail.gmail.com> (raw) In-Reply-To: <CACBZZX6Gad32eZX6BTamNK016wu3HHLdYDB6JkUPNv=+mB3PKg@mail.gmail.com> On Wed, May 17, 2017 at 12:45 PM, Ævar Arnfjörð Bjarmason <firstname.lastname@example.org> wrote: > On Wed, May 17, 2017 at 8:52 PM, Stefan Beller <email@example.com> wrote: >> On Wed, May 17, 2017 at 4:38 AM, Ævar Arnfjörð Bjarmason >> <firstname.lastname@example.org> wrote: >>> On Wed, May 17, 2017 at 9:09 AM, Junio C Hamano <email@example.com> wrote: >>>> Ævar Arnfjörð Bjarmason <firstname.lastname@example.org> writes: >>>> >>>>> On Wed, May 17, 2017 at 7:39 AM, Junio C Hamano <email@example.com> wrote: >>>>>> From: Marc Stevens <firstname.lastname@example.org> >>>>>> >>>>>> 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? Yes. Ouch. >> 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. I assumed more people would fetch git and trust the community rather than people checking if SHA1DC is up-to-date, so I thought it is easier for the minority to rewrite a URL. > 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". I would think so.
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] ` <email@example.com> 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 ` Ævar Arnfjörð Bjarmason 2017-05-17 18:52 ` Stefan Beller 2017-05-17 19:45 ` Ævar Arnfjörð Bjarmason 2017-05-17 19:57 ` Stefan Beller [this message] 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 ` 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='CAGZ79kZXgjC84vsXtvPu_=ApJOkAwUjV1BCS2iETowF-sSrrvw@mail.gmail.com' \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ /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
email@example.com 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