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
