Front page | perl.perl5.porters |
Postings from August 2009
2009/8/29 Yuval Kogman <nothingmuch@woobling.org>: > 2009/8/29 Rafael Garcia-Suarez <rgarciasuarez@gmail.com>: > >> I tend to prefer git-subtree, but it's only because I've heard bad >> things about submodules. > > I think most of the criticism is due to the fact that submodules are > not what people expect them to be. People tend to be deterred by the > fact that every time you update a submodule you need to commit to the > parent. That doesnt make me feel all warm and fuzzy frankly. Submodules to me still seem to be too unstable for us. I mean, we have a mostly git-unaware/novice user base, submodules seem to fox experienced users regularly. Using them for our community seems to me to be asking for trouble. Beside that they are cool and froody, whats the advantage? Especially given that our Dual-lifed modules arent necessary vc-ed under git anyway, whats the advantage of a submodule /at all/ in our case? >> So we'd need to host clones for each dual-life module ? (That's not a >> problem but I just want to make it clearer) > > Yes, otherwise instead of one point of failure for getting the code we > have as many failure points as there are module maintainers. > > Obviously they could be just mirrors though (so e.g. if I push to my > github version of Tie::RefHash and request integration to core, the > perl.git committer could update the perl5.git.perl.org mirror of my > .git, and then update that in the submodule). Reread that sentence about 10 times. Then ask yourself if you really think submodules are a good idea for us (now). Especially try to think of what would be involved explaining how to do this to the myriad CPAN owners. I mean, we arent even using the basic git features properly, and you want to throw in advanced features? (that IMO are seriously rough edged anyway) Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"Thread Previous | Thread Next