git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: Thomas Braun <thomas.braun@virtuell-zuhause.de>,
	Duy Nguyen <pclouds@gmail.com>,
	Junio C Hamano <gitster@pobox.com>,
	Jeffrey Walton <noloader@gmail.com>,
	Todd Zullinger <tmz@pobox.com>, Git List <git@vger.kernel.org>,
	Marc Stevens <marc@marc-stevens.nl>
Subject: Re: disabling sha1dc unaligned access, was Re: One failed self test on Fedora 29
Date: Tue, 12 Mar 2019 07:05:49 -0400	[thread overview]
Message-ID: <20190312110549.GC2023@sigill.intra.peff.net> (raw)
In-Reply-To: <8736nscw2y.fsf@evledraar.gmail.com>

On Tue, Mar 12, 2019 at 09:53:41AM +0100, Ævar Arnfjörð Bjarmason wrote:

> There's a at least a couple of aspects to this.
> 
> One is whether we should have the submodule in
> sha1collisiondetection/. I agree that's probably a bad idea now
> per-se. Honestly I wasn't expecting the answer when I submitted the
> final patch to switch to it fully to be to the effect of submodules
> being too immature for the git project itself to use. So now we're
> effectively mid-series, and should maybe just back out.

I think it's especially funky because we have three different ways of
getting sha1dc (in-tree, submodule, or against an external library). And
I almost blindly submitted a patch making the in-tree version work
(since that's what's used by default, and what I use) which could have
totally broken things for the other use cases without anybody realizing
until the change trickled down to somebody who uses those flags.

(Technically in this case it wouldn't actually have _broken_ them, but
just not helped them, so they'd be no worse off. But hopefully you get
the point).

Speaking of external libraries, in some ways the issue I raised is no
different than it is for any external library, where we're at the mercy
of whatever version is on the system. The big dependency for us is
usually libcurl, and we do have to sometimes work around old versions
there.

But I do think there's one thing that make the sha1dc submodule approach
more painful is that we don't control the content of the code, but we
_do_ build it ourselves with our usual compiler flags. So we're weirdly
intimate with it (and in fact, an external library would not have the
problem being discussed here, since it would have been built separately
without UBSan).

> I fully agree with what you've said in theory, but if we look at what's
> happened in practice we as a project are demonstrably not disciplined
> enough to manage upstream code like this without overtly perma-forking
> it.

I'm not sure I agree completely. Most of the things we've imported are
small enough that we're reasonably happy to accept them as a snapshot in
time and take ownership. I.e., I do not recall a lot of instances of
fixing bugs in compat/regex or compat/poll that we could have gotten
more easily by merging from upstream. But I admit I don't actually pay
much attention to those areas, so I might be completely off-base.

The one place I really _would_ have liked to remain compatible with
upstream is xdiff. And we were traditionally pretty hesitant to clean
things up there for fear of diverging. But in practice, upstream there
has been stagnant, and we've done most of the bug fixes and improvements
to it (in-tree).

> As far as I can tell none of the people changing that code went through
> the process of submitting a parallel upstream fix or seeing if the issue
> was fixed upstream and we could just update the code we were carrying,
> and of course that gets progressively harder for any one contributor as
> our divergence grows.

To be clear, I do sympathize with the notion that not pulling things
in-tree keeps our relationship with upstream more disciplined, and that
has value. I'm just not altogether clear how much it's really hurt us
overall to be undisciplined.

-Peff

  reply	other threads:[~2019-03-12 11:05 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-08 10:48 One failed self test on Fedora 29 Jeffrey Walton
2019-03-08 17:43 ` Todd Zullinger
2019-03-09 12:34   ` Jeffrey Walton
2019-03-09 13:12     ` Jeffrey Walton
2019-03-11  2:00       ` Junio C Hamano
2019-03-11  2:16         ` Jeffrey Walton
2019-03-11  3:37         ` disabling sha1dc unaligned access, was " Jeff King
2019-03-11 10:40           ` Jeffrey Walton
2019-03-11 18:19             ` Jeff King
2019-03-11 11:58           ` Duy Nguyen
2019-03-11 18:15             ` Thomas Braun
2019-03-11 18:23               ` Jeff King
2019-03-12  7:27                 ` Junio C Hamano
2019-03-12 10:51                   ` Jeff King
2019-03-13 11:47                     ` Thomas Braun
2019-03-13 15:39                       ` Jeff King
2019-03-13 16:00                         ` Ævar Arnfjörð Bjarmason
2019-03-12  8:53                 ` Ævar Arnfjörð Bjarmason
2019-03-12 11:05                   ` Jeff King [this message]
2019-03-12 12:09                     ` Ævar Arnfjörð Bjarmason
2019-03-12 21:01                       ` Jeff King
2019-03-12 21:06           ` [PATCH] Makefile: fix unaligned loads in sha1dc with UBSan Jeff King
2019-03-12 21:17             ` Ævar Arnfjörð Bjarmason
2019-03-12 21:19               ` Jeff King
2019-03-11  3:29     ` One failed self test on Fedora 29 Jeff King

Reply instructions:

You may reply publicly 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 using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190312110549.GC2023@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=marc@marc-stevens.nl \
    --cc=noloader@gmail.com \
    --cc=pclouds@gmail.com \
    --cc=thomas.braun@virtuell-zuhause.de \
    --cc=tmz@pobox.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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).