| 254 | | 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, (temporarily) [http://git-scm.com/docs/git-clone git-clone] the module or use [http://git-scm.com/docs/git-ls-remote git-ls-remote]. |
| 255 | | |
| 256 | | 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. 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. |
| | 254 | 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. |
| | 255 | |
| | 256 | 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. |
| | 257 | |
| | 258 | === Outline of git_subtree === |
| | 259 | |
| | 260 | One way to solve the problem would be a Drupal module which clones the git repository of each Drupal module locally (and probably caches the data), 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 hook_system_info_alter could then retrieve this information and induce it into the local Drupal ecosystem. By adding ''*.gitinfo'' to ''.gitignore'' we could be sure that these files do not cause problems with upstream changes of the modules' git repositories. |
