list mirror (unofficial, one of many)
 help / color / mirror / Atom feed
From: Jeff King <>
To: Thomas Braun <>
Cc: Junio C Hamano <>,
	Duy Nguyen <>,
	Jeffrey Walton <>,
	Todd Zullinger <>, Git List <>
Subject: Re: disabling sha1dc unaligned access, was Re: One failed self test on Fedora 29
Date: Wed, 13 Mar 2019 11:39:24 -0400
Message-ID: <> (raw)
In-Reply-To: <>

On Wed, Mar 13, 2019 at 12:47:51PM +0100, Thomas Braun wrote:

> > Reading Thomas's email again, that might actually have been what he was
> > recommending. If so, sorry for the confusion. And I agree that's a valid
> > solution.
> Yes that is what I tried to explain. Looks like it was lost in translation.

I think the problem was on the reading end. :)

> > That said, I do wonder at some point if there's a huge value in using a
> > submodule at that point. I think there is if the dependent project is
> > large (and if it's optional, and some people might not need it). But in
> > this case, it is not a big deal to just carry the sha1dc code in-tree.
> A big win with submodules is that you have separate histories and can,
> quite easily, update to newer versions without manual copying.

True. We'd generally be picking up snapshots in our in-tree sha1dc/, so
bisecting on it is not as fine-grained. We _could_ pull in the full
history using something like git-subtree, but that comes with its own

> One grievance with submodules is the URL switching if you need to go
> with a forked repo for some time and then back to the original.
> Is it possible to have multiple remotes for a submodule?
> Something like:
> [submodule "libfoo"]
> 	path = include/foo
> 	url1 = git://
> 	url2 = git://
> With that the error prone git submodule sync step is not required anymore.

I assume you'd fetch from _all_ of them during a fetch, and assume that
one of them will get you the objects you need (or I guess if you are
looking for a specific object, you'd try them one at a time until you
get the object).

That makes sense, though it might be kind of annoying when fetching is
expensive (especially if it involves manually authenticating).

> submodule.alternateLocation looks like it is going into the right direction.

I think that's mostly about pointing back to the superproject for local
storage. Though I think there's a pretty reasonable solution to the
problem we're discussing there: git.git could carry a "sha1dc" branch
that points to our modified submodule history. So it's "in-tree" in the
sense that that it is in our repo, and under our full control, but still
managed like a submodule.

And we'd probably not even duplicate a lot of storage in the actual
clone of the upstream project, because it would be pointing to us as an


  reply	other threads:[~2019-03-13 15:40 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-08 10:48 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 [this message]
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
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:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link list mirror (unofficial, one of many)

This inbox may be cloned and mirrored by anyone:

	git clone --mirror
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 git git/ \
	public-inbox-index git

Example config snippet for mirrors.
Newsgroups are available over NNTP:
 note: .onion URLs require Tor:

code repositories for the project(s) associated with this inbox:

AGPL code for this site: git clone