>> 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. > I wasn't wanting to do pull there - but either way, I agree :-) >> 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. :-) > Hmm. Locally modifying my .gitmodules still feels bad because I don't like either of those tradeoffs (but I don't have any sensible suggestion yet). As a bit of background (as to why I'd dislike (a) and (b)), we had a team switch to git, and one of the really nice things is the ability to share stuff around and branch freely - but the flipside of that is that we tend to push to a central repo more rarely, so the advantages of an continuous integration server become less. What we did is to tell a centralised CI server the URLs of all the team's git repositories, and it would periodically pull from them, speculatively compile anything new, and run the big suite of tests - finishing up by emailling them a heads-up that a particular state in their repo is 'bad'. This was really popular as it was demonstrably better than anything we could do with svn, and best of all, it's pretty much transparent - as a user you don't have to do anything at all. I could do it now by hacking about with files; it'd just be nice to keep it transparent and make it a directly supported feature. -- 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
