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

From: Jeff King <peff@peff.net>
Date: Mar 13, 2019, 15:39 UTC
Message-ID: <20190313153923.GC24101@sigill.intra.peff.net>
In-Reply-To: <7435b80b-6bd7-cab9-c646-5c81b639f117@virtuell-zuhause.de>

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

Show 5 quoted lines

> > 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. :)

Show 7 quoted lines

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

Show 12 quoted lines

> 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