Changes between Version 4 and Version 5 of faq/gitification


Ignore:
Timestamp:
May 25, 2012, 6:02:09 PM (7 years ago)
Author:
Bart
Comment:

Added core chapter

Legend:

Unmodified
Added
Removed
Modified
  • faq/gitification

    v4 v5  
    33== Introduction ==
    44
    5 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 modules. 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.
     5Until 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.
    66
    7 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 complicated, unintuitive and detested by many for good reasons. But as git follows the [http://en.wikipedia.org/wiki/There%27s_more_than_one_way_to_do_it 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.
     7Since 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.
    88
    99== Drupal core ==
    1010
    11 We create a new directory, initialise git, add pressflow as a new remote and fetch it:
     11We 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:
     12
    1213{{{
    1314mkdir liu_d6
    1415cd liu_d6
    1516git init
     17git config user.name "Indymedia linksunten"
     18git config user.email "línksunten@índymedía.org"
     19touch liu_d6
     20git add liu_d6
     21git commit -m "Initial commit Indymedia linksunten Drupal 6."
     22git rm liu_d6
     23git commit -m "Created master branch."
     24}}}
     25
     26We don't want the settings.php file in our repository as it contains database login credentials so we tell git to exclude it:
     27{{{
     28echo /settings.php >> .git/info/exclude
     29}}}
     30
     31We add Pressflow 6 as a new remote and fetch it:
     32{{{
    1633git remote add pressflow-6.x git://github.com/pressflow/6.git master
    1734git fetch pressflow-6.x
    1835}}}
     36
     37Now 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:
     38{{{
     39git subtree add --squash --prefix=core pressflow-6.x/drupal-6.26
     40}}}
     41
     42As we are creating a production environment, we'll delete some of the unnecesary files:
     43{{{
     44git rm core/install.php core/*.txt
     45git commit -m "Delete install.php and text files from core directory."
     46}}}
     47
     48We copy our settings.php to our repository directory, create a symbolic link from inside the core and delete the default.settings.php
     49{{{
     50cp ~/settings.php .
     51cd core/sites/default
     52ln -s ../../../settings.php
     53git rm default.settings.php
     54cd ../../../
     55git add core/sites/default/settings.php
     56git commit "Add symbolic link to settings.php."
     57}}}
     58
     59There 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.