On Wed, Mar 13 2019, Jeff King wrote: > 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. Now if only we could think of some way to give the people best positioned to fix some of these UI issues for git users everywhere the incentive to do so[1] :) 1. https://public-inbox.org/git/20171208223001.556-5-avarab@xxxxxxxxx/
