Front page | perl.perl5.porters |
Postings from August 2009
demerphq wrote: >>> 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. > However, it does mirror current practice; development on modules generally continue separately and out of band to perl; and then you have commits which update the version in blead etc to the latest version of the module. > 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? > Submodules have one advantage over sub-tree merging, in that the history of the submodule, which generally will be of little interest to people working with perl.git, will be stowed away inside the submodule. with git-subtree, it's basically another branch so you'll end up with commits on the sub-project intermingled with the main commit graph. Another advantage of submodules vs the current system it is that the module author does not need to do anything; they just make their source code available. If it is not in git, it can be tracked/imported (I have registered the 'cpan' github account should someone want to take up such a project), and then used as a submodule. The only real disadvantage is an extra step after clone required to populate the submodules. Also, it is possible to end up pushing stuff no-one can clone if you are not careful. But these problems can be solved by supplying a script to populate the submodule directories if not present, and set up a safety hook (see http://marc.info/?l=git&m=124140813023956&w=2 for the basic idea). This can be called by the make/Configure process when building from a git source. Submodules are by no account "unstable"; the merged implementation was the third generation and is very solid, and like the rest of git understanding follows quickly from knowing how it fits with the git basics; - in the tree object, instead of a tree or a blob, you have a "commit" SHA1 - /.gitmodules has the URL corresponding to that path - objects for the submodule are stored separately under submodule/.git - the submodules only change commit when you tell them to - with the commit checked out that you want, 'git add' the submodule like a regular file Of course the man pages and tutorials will go into more detail, but there is a very simple overview. SamThread Previous | Thread Next