Am 12.03.2019 um 11:51 schrieb Jeff King: > On Tue, Mar 12, 2019 at 04:27:57PM +0900, Junio C Hamano wrote: > >> Jeff King <peff@xxxxxxxx> writes: >> >>> The problem to me is not that the steps that a developer has to do, but >>> rather that we are dependent on the upstream project to make a simple >>> fix (which they may not agree to do, or may take a long time to do). >> >> Yeah. In practice, I think the recommended way to work for a >> depending project like us is to keep a fork in a separate repository >> we control of the submodule project, and allow our fork to be >> slightly ahead of the upstream while feeding our change to them. > > 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. > 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. 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. submodule.alternateLocation looks like it is going into the right direction.
