On Jan 27, 2008 1:39 PM, Jakub Narebski <jnareb@xxxxxxxxx> wrote: > A bit of time ago I have stumbled upon the following blog entry > (question): "Agaric wants version control that lets Drupal core and > contrib replace entire directories within our checkouts"[1] > http://tinyurl.com/yv3jp4 While it is possible to use submodules, I tend to think that you can just use your own repo / branch "off" the main project, just like unofficial kernel modules do. It does have a number of advantages -- including being explicit wrt to what version of the core project the module is developed against. Drupal and similar projects (like Moodle) do have a module API, but it's not *that* stable -- in spite of the best intentions, those APIs get subtle changes all the time. You should have your "release" script package only the module subdirectories -- and perhaps any delta in the core (of Drupal) that needs to be applied. In many "contrib" projects I've seen module files and little patch files that you are supposed to apply - and maintenance of those is a pain. It makes more sense to use git over the whole tree. So it's a tradeoff -- IMHO, at first blush it looks more "natural" to use submodules, but as things progress over time I think it forces a lot of additional and ill-fitted work like maintaining patches, or adding tags that indicate "developed against Drupal v1.2.3". And the day the contrib module becomes official, "merging it in" is a bit of a mess if you want to preserve history. So in the long haul, it makes a lot more sense to use the "branch off the full project" approach that has served the kernel modules so well. In that sense, I think that gitk's tree getting merged in a subdirectory is good as an example of what git can do, but a bit pointless as gitk depend quite tightly on the behaviour of git commands. So distributing gitk separately would be a big pain as each gitk version is usable against a narrow set of git revisions. Luckily, it gets merged into git and that's how it gets distributed. My .2c anyway ;-) m - 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
