On Fri, Jul 18, 2008 at 11:00 AM, Petr Baudis <pasky@xxxxxxx> wrote: > On Fri, Jul 18, 2008 at 10:36:51AM +0100, Nigel Magnay wrote: >> On Fri, Jul 18, 2008 at 10:16 AM, Petr Baudis <pasky@xxxxxxx> wrote: >> > snip >> > >> > "How do we mass-supply custom submodule URLs when publishing the >> > customized main repository at a custom location too?" >> > >> Yes - that is an additional problem. > > Wait, I'm lost again - _additional_ problem? How does it differ from the > _original_ problem, how does it differ from what you're explaining below > and how does what you're explaining below differ from the original > problem? > In addition to the problem of needing to execute multiple commands and edit files to acheive what is a rather simple usecase, there is the additional problem of discovering (for a third party) a url for where their submodules are stored. > Or are we talking exclusively about what I summed up above now? > In this part of the thread. The first part seems to have broad agreement that a command could be added / modified, but not yet what it should look like. >> If I may expand the usecase just so it's clear (and to check we're >> talkiing the same language) >> >> I do something like >> $ git remote add fred git://fredcomputer/superproject/.git >> $ git fetch --submodules fred > > I think you mean git pull --submodules fred. Well, actually, you want to > pull the main repository, then submodule update (_not_ pull in the > submodules). See? This is part of the "semantic swamp" I mentioned > before. Ah - I understand. You're saying "you can't pull submodules when you pull the supermodule, because you don't know which submodules might be needed until you also merge / checkout the desired revision" ? Ack. > > I think it should be somehow part of the _main_ project's fred branch > that in this branch, the subprojects should be fetched from a different > location; thus, you would still do > > $ git remote add fred git://fredcomputer/superproject/.git > $ git pull fred > $ git submodule update > Yes, that makes sense. > where either the submodule update takes the info from fred's adjusted > .gitmodules, or it is an implicit part of the branch as in fred tells > you to run the update command with some extra arguments. > > However, I still believe the information should primarily stem from the > main repository; consider e.g. if you do not have some of the submodules > checked out when you switch to fred, then figure out that in fred's > branch, you really do want them checked out. > Yes. Referring to your earlier mail, I'm now preferring "(4) Something else that I'm not realizing." ;-) Hm. It feels like each person could have some 'local' info in their .gitmodules, and rules around merging; but I'm not sure of exactly what, or how. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
