= Gitification of Indymedia linksunten = == Introduction == Until May 2012,[https://linksunten.indymedia.org/ Indymedia linksunten] used the Good Old Fashioned Way™ to keep track of upstream changes to it's [http://drupal.org/ Drupal] (in fact: [http://pressflow.org/ Pressflow]) core and modules: [http://drupal.org/project/drush drush] dl mymodule. At least in theory. In reality, the core has been patched twice, many modules even more and some self-written modules do not even exist in a public drupal repository. linksunten has some 80 modules installed and keeping track of updates is wearisome for the non-patched modules and troublesome for the patched ones. We learned that a version control system could ease the error-prone update procedure and as drupal.org has switched to [/wiki/git git] we decided to do the same. Since a Drupal website is not a monolithic bloc and nearly each module is maintained by different developers we needed to find a way to update the core and each module separately from one another. The traditional way git offers for this is a concept called [http://git-scm.com/book/en/Git-Tools-Submodules git-submodule]. It is complicated, unintuitive and detested by many for good reasons. But as git follows the [http://docstore.mik.ua/orelly/weblinux2/modperl/ch13_01.htm TMTOWTDI] paradigm we could avoid using git-submodule and settled for [https://github.com/apenwarr/git-subtree git-subtree] instead which has recently been [https://github.com/apenwarr/git-subtree/commit/8cd698957f57f62ec3d313403bebced2fdf751e5 merged] into git core. Besides the possibility to update the core and each module separately and replaying our patches to the updated version automatically, we want the linksunten code to be one git repository which simply "works" after cloning it. After our move to git we will use the [http://drupal.org/project/features features] module to version control as much of our configuration data as possible. == Drupal core == We create a new directory, initialise git, tell git which name and email to use, create a temporary file which we commit, delete and commit again to create a master branch: {{{ mkdir liu_d6 cd liu_d6 git init git config user.name "Indymedia linksunten" git config user.email "línksunten@índymedía.org" touch liu_d6 git add liu_d6 git commit -m "Initial commit Indymedia linksunten Drupal 6." git rm liu_d6 git commit -m "Created master branch." }}} We don't want the settings.php file in our repository as it contains database login credentials so we tell git to exclude it: {{{ echo settings.php >> .git/info/exclude }}} We add Pressflow 6 as a new remote and fetch it: {{{ git remote add pressflow-6.x git://github.com/pressflow/6.git master git fetch pressflow-6.x }}} Now we can add Drupal core from our pressflow-6.x remote via git-subtree in a subdirectory core. We use the --squash parameter as we do not need the whole commit history of Pressflow in our master branch: {{{ git subtree add --squash --prefix=core pressflow-6.x/drupal-6.26 }}} As we are creating a production environment, we'll delete some of the unnecesary files: {{{ git rm core/install.php core/*.txt git commit -m "Delete install.php and text files from core directory." }}} We copy our settings.php to core/sites/default and delete the default.settings.php: {{{ cp ~/settings.php core/sites/default git rm core/sites/default/default.settings.php git commit -m "Deleted default.settings.php." }}} There are some more modifications to do but they are really linksunten specific (like applying the two core patches via {{{git am}}} which have been created via {{{git format-patch}}} before) so we leave them out. == Drupal modules == Normally, Drupal modules are installed under sites/default/modules. This would be fine with our approach but it would create unnecessary huge merges when updating the core and it keeping all parts separately accessible from the root directory of our installation is much clearer arranged. So we create a modules (and perhaps also a files, libraries and themes) directory, a symbolic link to it and add commit the link: {{{ mkdir modules cd core/sites/default ln -s ../../../modules cd ../../../ git add core/sites/default/modules git commit -m "Add symbolic link to modules directory." }}} Now we install a module in it. As an example we chose the [http://drupal.org/project/i18n i18n] module. At the Drupal project page we click on the green "Version Control" tab and chose "Version to work from: 6.x-1.x". There we get the URL which we need to add the repository as a remote repository. The parameter -f triggers an instant fetch: {{{ git remote add -f i18n-6.x-1.x http://git.drupal.org/project/i18n.git 6.x-1.x }}} Now we do not install the latest version 6.x-1.10 but version 6.x-1.9. The reason is that we have patched that version and we want to use git-subtree and [http://git-scm.com/book/en/Git-Branching-Rebasing git-rebase] to reapply our patches to the newest version. First, we install 6.x-1.9: {{{ git subtree add --squash --prefix="modules/i18n" 6.x-1.9 }}} Then we overwrite the newly imported files with our patched version and commit the patches. At this point, [http://git-scm.com/book/ch6-2.html interactive staging] might be a good idea. {{{ cp ~/i18n.module modules/i18n cp ~/i18nsync.module modules/i18n git add modules/i18n/i18n.pages.inc git commit -m "i18n: Exchange title with nid in translation box." git add modules/i18n/i18nsync/i18nsync.module git commit -m "i18n: Inherit path when syncing." }}} == Update a patched module == First, we create a new [http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging branch] containing the version of our module we want to update to. As we have already added i18n as a remote we can checkout the desired version in a separate branch using the corresponding [http://git-scm.com/book/en/Git-Basics-Tagging tag]. As long as there are no [http://git.661346.n2.nabble.com/1-8-0-Remote-tag-namespace-td5980437.html separate namespaces for remote tags] in git we definitely want to start with a git fetch to be sure to refer to tag of the right module: {{{ git fetch i18n-6.x-1.x git branch i18n-6.x-1.10 6.x-1.10 }}} Then we extract the patched version of our module into a branch along with it's history: {{{ git subtree split --rejoin --prefix=modules/i18n --branch=i18n-linksunten }}} Now we can rebase our branch on top of the new version of the module: {{{ git rebase i18n-6.x-1.10 i18n-linksunten }}} Finally, we have to merge the patched new version into our master branch: {{{ git subtree merge --squash --prefix=modules/i18n i18n-linksunten }}} After that, you can delete the two branches: {{{ git branch -D i18n-6.x-1.10 i18n-linksunten }}}