Changes between Version 6 and Version 7 of faq/gitification
- Timestamp:
- May 26, 2012, 12:55:10 AM (13 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
faq/gitification
v6 v7 25 25 We don't want the settings.php file in our repository as it contains database login credentials so we tell git to exclude it: 26 26 {{{ 27 echo /settings.php >> .git/info/exclude27 echo settings.php >> .git/info/exclude 28 28 }}} 29 29 … … 45 45 }}} 46 46 47 We copy our settings.php to our repository directory, create a symbolic link from inside the coreand delete the default.settings.php:47 We copy our settings.php to core/sites/default and delete the default.settings.php: 48 48 {{{ 49 cp ~/settings.php . 50 cd core/sites/default 51 ln -s ../../../settings.php 52 git rm default.settings.php 53 cd ../../../ 54 git add core/sites/default/settings.php 55 git commit "Add symbolic link to settings.php." 49 cp ~/settings.php core/sites/default 50 git rm core/sites/default/default.settings.php 51 git commit "Deleted default.settings.php." 56 52 }}} 57 53 … … 60 56 == Drupal modules == 61 57 62 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 and a symbolic link to it:58 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: 63 59 {{{ 64 60 mkdir modules … … 66 62 ln -s ../../../modules 67 63 cd ../../../ 64 git add core/sites/default/modules 65 git commit -m "Add symbolic link to modules directory." 68 66 }}} 69 67 … … 89 87 }}} 90 88 91 As our core directory is not empty, we can add the symbolic link to our modules directory: 89 == Update a patched module == 90 91 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: 92 92 {{{ 93 git add core/sites/default/modules94 git commit -m "Add symbolic link to modules directory."93 git fetch i18n-6.x-1.x 94 git branch i18n-6.x-1.10 6.x-1.10 95 95 }}} 96 96 97 == Update a patched module == 97 Then we extract the patched version of our module into a branch along with it's history: 98 {{{ 99 git subtree split --rejoin --prefix=modules/i18n --branch=i18n-linksunten 100 }}} 98 101 102 Now we can rebase our branch on top of the new version of the module: 103 {{{ 104 git rebase i18n-6.x-1.10 i18n-linksunten 105 }}} 106 107 Finally, we have to merge the patched new version into our master branch: 108 {{{ 109 git subtree merge --squash --prefix=modules/i18n i18n-linksunten 110 }}} 111 112 After that, you can delete the two branches: 113 {{{ 114 git branch -D i18n-6.x-1.10 i18n-linksunten 115 }}