Changes between Version 25 and Version 26 of faq/gitification

Timestamp:

May 29, 2012, 12:00:19 AM (12 years ago)

Author:

Bart

Comment:

--

faq/gitification

@@ -123 +123 @@
 == hook_system_info_alter ==
 
-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 release version of many modules are not tagged at all.
-
-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''.
+In the past, drupal.org used [http://www.nongnu.org/cvs/ CVS] as version control system and switched to git only 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.
+
+Another problem is the available updates page at ''/admin/reports/updates'' and the version information obtained by [http://api.drush.org/api/drush/commands!pm!pm.drush.inc/function/drush_pm_list/5.x drush pm-list]. When checking out a module via git no version information is 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''.
 
 === git_deploy 6.x-2.x ===
@@ -228 +228 @@
 === Analysis of git_deploy ===
 
-Version 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.
+Version 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 the idea of git_deploy 2.x to git-subtree.
 
 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. 
@@ -252 +252 @@
 }}}
 
-This 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 [https://github.com/apenwarr/git-subtree/blob/master/git-subtree.txt 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, use [http://git-scm.com/docs/git-ls-remote git-ls-remote] to search git.drupal.org or (temporarily) [http://git-scm.com/docs/git-clone git-clone] the module.
-
-Keeping 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. git-ls-remote is too slow when having lots of modules installed and searching through remote repositories does not feel right at all. So the only remaining way to go is to clone the repository to determine the necessary info locally.
+This approach won't work for git-subtree as there is no mapping of modules to remotes and remotes are not exported. So a [http://git-scm.com/docs/git-clone git-clone] won't know the original fetch urls used for [https://github.com/apenwarr/git-subtree/blob/master/git-subtree.txt git-subtree-add]. Fortunaltely, drupal.org uses well-defined fetch urls so we can reconstruct the information by sanning for .modules files. 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, use [http://git-scm.com/docs/git-ls-remote git-ls-remote] to search git.drupal.org or (temporarily) [http://git-scm.com/docs/git-clone git-clone] the module.
+
+Keeping 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. git-ls-remote is too slow when having lots of modules installed and searching through remote git repositories does not feel right at all. So the only sensible way seems to be to clone the repository and determine the necessary info locally.
 
 === Outline of git_subtree ===
 
-One way to solve the problem would be a Drupal module which uses the [http://api.drush.ws/api/drush/docs!drush.api.php/5.x Drush api] to clone the git repository of each Drupal module locally, determines the version information by using the ''git-subtree-split'' line returned by [http://git-scm.com/docs/git-log git-log] and writes this information to a ''.gitinfo'' file. A [http://api.drupal.org/api/drupal/developer!hooks!core.php/function/hook_system_info_alter/6 hook_system_info_alter] could then retrieve this information and induce it into the local Drupal ecosystem. By adding ''*.gitinfo'' to [http://git-scm.com/book/en/Git-Basics-Recording-Changes-to-the-Repository .gitignore] we could be sure that these files do not cause any problems when syncing upstream repositories.
+One way to solve the problem would be a Drupal module which uses the [http://api.drush.ws/api/drush/docs!drush.api.php/5.x Drush api] to clone the git repository of each Drupal module locally and then determines the version information by using the ''git-subtree-split'' line returned by [http://git-scm.com/docs/git-log git-log]. It could write this information to a ''mymodule.gitinfo'' file. A module could then retrieve this information from the ''mymodule.gitinfo'' file and a [http://api.drupal.org/api/drupal/developer!hooks!core.php/function/hook_system_info_alter/6 hook_system_info_alter] could induce it into the local Drupal ecosystem. By adding {{{*.gitinfo}}} to [http://git-scm.com/book/en/Git-Basics-Recording-Changes-to-the-Repository ''.gitignore''] we could be sure that these files do not cause any problems when syncing with upstream repositories.