Changes between Version 18 and Version 19 of faq/gitification


Ignore:
Timestamp:
May 28, 2012, 9:56:15 AM (8 years ago)
Author:
Bart
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • faq/gitification

    v18 v19  
    9292== Update ==
    9393
    94 We are going to update a patched Drupal module using git-subtree and 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 a git fetch to be sure to refer to tag of the right module:
     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 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:
    9595{{{
    9696git fetch i18n-6.x-1.x
     
    230230Version 1.x of git_deploy was based on [https://github.com/patrikf/glip glip], a Git Library In PHP. Version 2.x of git_deploy calls the git executable directly and parses the output instead. There might be issues in a shared hosting environment but many people report that the 2.x version works far better than the 1.x version, so we'll adapt git_deploy 2.x to git-subtree.
    231231
    232 Let's analyse what git_deplploy does. The module implements only one hook: [http://api.drupal.org/api/drupal/developer!hooks!core.php/function/hook_system_info_alter/6 hook_system_info_alter]. With this hook the module info obtained through git can be induced. But the module searches for a ''.git'' directory, so it only works for git-submodules in the current version.
     232Let's analyse what git_deplploy does. The module implements only one hook: [http://api.drupal.org/api/drupal/developer!hooks!core.php/function/hook_system_info_alter/6 hook_system_info_alter]. With this hook the module info obtained through git can be induced.
     233
     234git_deploy searches for the ''.git'' directory of the module, so it will only work for git-submodules:
    233235{{{
    234236      while ($directory && !is_dir("$directory/.git")) {
     
    237239}}}
    238240
    239 It uses the Fetch URL obtained by {{{git remote show -n origin}}} to determine the project name. This won't work with git-subtree as remotes are usually not exported so a clone won't know the original fetch urls used for {{{git subtree add}}}. Fortunaltely, drupal.org uses well-defined fetch urls so we can reconstruct the information. But the process will be much more time-consuming with git-subtree than it is with git-submodule.
     241git_deploy then uses the fetch url obtained by {{{git remote show -n origin}}} to determine the project name:
    240242{{{
    241243        exec("$git remote show -n origin 2>&1", $output);
     
    249251        }
    250252}}}
     253
     254This approach won't work for git-subtree as remotes are not exported so a [http://git-scm.com/docs/git-clone git-clone] won't know the original fetch urls used for {{{git subtree add}}}. Fortunaltely, drupal.org uses well-defined fetch urls so we can reconstruct the information. But the process will be much more complicated and time-consuming with git-subtree than it is with git-submodule as we would either have to keep the module's history in a separate branch, incorporate the whole history by not using the --squash parameter, (temporarily) clone the module or use [http://git-scm.com/docs/git-ls-remote git-ls-remote].
     255
     256Keeping the whole history in a separate branch would work but this is a fragile approach because we'd lose the liberty to mess around with our repository which is one of the key advantages of the git-subtree approach compared to the git-submodule one. We do want to use the --squash parameter to keep the overall size of the git repo small and the git history uncluttered. So the only remaining way to go is to either clone the repository to determine the necessary info locally or use git-ls-remote to search on git.drupal.org.