Re: disabling sha1dc unaligned access, was Re: One failed self test on Fedora 29

[Jeff King <peff@peff.net>]

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

> 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://foo.com/upstream/lib.git
> 	url2 = git://foo.com/myFork/lib.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
alternate.

-Peff