Changes between Version 19 and Version 20 of faq/gitification


Ignore:
Timestamp:
May 28, 2012, 2:10:13 PM (13 years ago)
Author:
Bart
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • faq/gitification

    v19 v20  
    99Since 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] and [http://drupal.org/project/ctools ctools] modules to version control as much of our configuration data as possible.
    1010
    11 == Installation ==
     11== Drupal installation ==
    1212
    1313=== Drupal core ===
    1414
    15 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:
     15We create a new directory, run [http://git-scm.com/docs/git-init git init], use [http://git-scm.com/docs/git-config git-config] to specify which name and email to use, create a temporary file which we commit, delete and commit again to create a master branch:
    1616{{{
    1717mkdir liu_d6
    … …  
    5656}}}
    5757
    58 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.
     58There are some more modifications to do (like [http://git-scm.com/book/en/Distributed-Git-Maintaining-a-Project applying] two core patches using [http://git-scm.com/docs/git-am git-am] which have been [http://git-scm.com/book/en/Distributed-Git-Contributing-to-a-Project created] with [http://git-scm.com/docs/git-format-patch git-format-patch] before) but they are really specific to Indymedia linksunten so we leave them out.
    5959
    6060=== Drupal modules ===
    … …  
    9090}}}
    9191
    92 == Update ==
    93 
    94 We are going to update a patched Drupal module using [https://github.com/apenwarr/git-subtree/blob/master/git-subtree.txt git-subtree] and [http://git-scm.com/docs/git-rebase git-rebase]. 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 [http://git-scm.com/docs/git-fetch git-fetch] to be sure to refer to tags of the right module:
     92== Drupal update ==
     93
     94We are going to update a patched Drupal module using [https://github.com/apenwarr/git-subtree/blob/master/git-subtree.txt git-subtree] and [http://git-scm.com/docs/git-rebase git-rebase]. 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 [http://git-scm.com/docs/git-remote git-remote] we can [http://git-scm.com/docs/git-checkout git-checkout] (as a shortcut for [http://git-scm.com/docs/git-branch git-branch]) 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 [http://git-scm.com/docs/git-fetch git-fetch] to be sure to refer to tags of the right module:
    9595{{{
    9696git fetch i18n-6.x-1.x
    … …  
    103103}}}
    104104
    105 Now we can rebase our branch on top of the new version of the module:
     105Now we can [http://git-scm.com/docs/git-rebase git-rebase] our branch on top of the new version of the module:
    106106{{{
    107107git rebase i18n-6.x-1.10 i18n-linksunten
    108108}}}
    109109
    110 Finally, we have to merge the patched new version into our master branch:
     110Finally, we have to subtree merge the patched new version into our master branch:
    111111{{{
    112112git checkout master
    … …  
    119119}}}
    120120
    121 The same process can be applied to update the core. Hopefully, you did not need to patch the core (as we did) so a {{{git fetch}}} will reside in [http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging fast-forward merges]
    122 
    123 == Literally controlling versions with git_deply ==
    124 
    125 In the past, drupal.org used [http://www.nongnu.org/cvs/ CVS] as version control system and switched to git quite recently. Unfortunately, not all module maintainers have adapted their code base to the new revision control system manually. Instead, the Drupal team migrated lots of projects automatically. So at least at the moment, you'll discover that the module releases are not tagged ad all.
    126 
    127 Another problem is the available updates page at ''/admin/reports/updates''. When checking out a module via git there are no version information added by the drupal.org package manager. Enter [http://drupal.org/project/git_deploy git_deploy]. More precisely, commit 68bd1a8219cbe59e7fbe56b317a600321116ddfa from Thu Apr 26 10:15:16 2012 -0700.
     121The same process can be applied to update the core. Hopefully, you did not need to patch the core (as we did) so [http://git-scm.com/docs/git-fetch git-fetch] will result in [http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging fast-forward merges].
     122
     123== hook_system_info_alter and .info files ==
     124
     125In the past, drupal.org used [http://www.nongnu.org/cvs/ CVS] as version control system and switched to git quite recently. Unfortunately, not all module maintainers have adapted their code base to the new revision control system manually. Instead, the Drupal team migrated lots of projects automatically. So at least at the moment, you'll discover that release version of many modules are not tagged at all.
     126
     127Another problem is the available updates page at ''/admin/reports/updates''. When checking out a module via git there are no version information added by the drupal.org package manager. Enter [http://drupal.org/project/git_deploy git_deploy]. More precisely ''commit 68bd1a8219cbe59e7fbe56b317a600321116ddfa'' from ''Thu Apr 26 10:15:16 2012 -0700''.
    128128
    129129=== git_deploy 6.x-2.x ===