Hello, Tibor asked me to have a look at the various ways how to include the new modules into the git. Currently, there are two modules that need integration - both of them are to become part of the Invenio in the near future: 1) the new workflow engine, 2) the solr-invenio search (in the case of the workflow engine, the git integration is the only thing that holds us back)
Problem: The modules need to be exportable independently of the whole master but git does not allow to checkout/export of the parts of the source tree Why we need it?: The workflow engine as well as the solr integration are generic (more people use them, more bugs discovered, more features added). Workflow engine was developed originally for another project, which is still using it, therefore it must be possible to export the workflow engine separately. And forking is not nice and cool. The same applies to the solr integration. Solution: ??? --- To my mind, after doing a lot of reading (please see details below), it seems that the right way to go is the git subtree -- that is the Git canonical way, it is standard and follows the git model. The other solutions (like symbolic links, or git subtree) are really cumbersome. But it would be really nice if we could find some solution quickly. Details: ----- git submodule - allows to include a separate module into the main repository - but it points to the particular commit - it is not possible to reference symbolic commits (eg. submodule-x/HEAD) - the head is in the detached state - it is worrying that submodule *assumes* that you will not make mistakes I have found worrying number of posts where developers shot their own feet using submodule, eg. - http://pkp.sfu.ca/wiki/index.php/Frequent_git_use_cases#Gotchas_and_best_practices_for_submodule_.22symlink.22_maintenance - http://progit.org/book/ch6-6.html Also one git plugin was created to prevent that (a good illustration of what one needs to do when using submodule): http://flavoriffic.blogspot.com/2008/05/managing-git-submodules-with-gitrake.html ----- The git-native way of doing things, however, seems to be the git subtree: http://progit.org/book/ch6-7.html - the remote module is included inside the tree (it is copied) - it is not the same as submodule, but it has the same effect as git submodule - Tibor can have the same level of control (eg. for master branch, clone the particular commit; for dev branch insert other commit) - but gittree seems more ROBUST (does not require you to remember to do certain operations in order) - people can update the remote submodule and the changes will be visible in the main superbranch (if that branch was pointing to the remote/HEAD) - it works like a normal git merge links: http://progit.org/book/ch6-7.html http://stackoverflow.com/questions/2879414/git-submodule-svn-external RELATED: - about submodule, good descr: http://panthersoftware.com/articles/view/3/svn-s-svn-externals-to-git-s-submodule-for-rails-plugins The other sensible option is to use symlinks - however, in that case we cannot say that master branch should see HEAD and the release-X should point to commit Y of the remote module.
