On Fri, Jul 18, 2008 at 12:20:13PM +0100, Nigel Magnay wrote: > 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. I see. That's interconnected as a single "How to check Fred's work" problem for me. :-) > >> 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. That is something I might agree with, but my point is that within the submodule, git pull simply isn't a sensible operation at all! You don't want to do any merges or whatever, just bring the submodule to a defined commit id. So you want to do something significantly different: git fetch git reset --hard <commitid> And that's what 'git submodule update' already does. > 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. Again, when customizing .gitmodules, you need to either give up on (i) bisectability; it's not good enough to restore the canonical .gitmodules contents on merge, since the bisect can run into one of the commits on fred' branchs (ii) publishing the exact same branch for testing and merging But I start to feel that the tradeoff of (ii) is really not so bad at alland this would be perhaps the most elegant solution. You can either (a) make two parallel branches, one with your .gitmodules and one with the upstream's (b) probably better, stick a commit at the top of your branch that will change .gitmodules to your locations; others can check out fred, test things out, then merge fred^; you can even generally go back in fred's commits if you just 'git submodule update' right after checking fred out, since all the required submodule commits will be probably already fetched. So I say just go for the (ii)-(b) combination. :-) -- Petr "Pasky" Baudis As in certain cults it is possible to kill a process if you know its true name. -- Ken Thompson and Dennis M. Ritchie -- 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
