Git subtree with add-ons that have a themes folder

Question

I've taken to installing add-ons that I have in development in separate repositories as submodules into each of my EE projects. This has worked fine for add-ons that do not have a themes folder, but I am now finally in the situation where I want to develop a module/extension that utilizes a themes folder.

I have come accross this other question for which answers suggest using symlinks to accomplish the goal. I find symlinks in git to be a scary proposition (they don't behave the same across platforms), and would prefer to have a way to do this that refers to the remote repo, not a local copy by a strict path.

Is there a way to use subtree merging to remap e.g.:

• subproject/system/expressionengine/third_party/add-on-name to project/third_party/add-on-name (I use ee-master-config to remap third_party outside of the expressionengine directory, along with the templates directory)
• subproject/themes/third_party/add-on-name to project/public_html/themes/third_party/add-on-name (I keep the system folder above web root)?

To clarify the setup, this is my current folder hierarchy for any given EE site:

/public_html
  /public_html/themes
  /public_html/system (contains only an index.php pointing to ../../system)
/system
/templates
/third_party

Web root is set to public_html so that executable server side code is never exposed to the wider world. In an add-on repository the folder structure is that of the default expressionengine setup, eg.:

/system
  /system/expressionengine/third_party
/themes

The trouble then is including the files from the add-on repository to different paths in an expressionengine site's hierarchy.

Answer 1

I'm not too well versed in Git, but you could override the third party path for addon's in the system/expressionengine/config/config.php file and put site & addon assets in a folder outside of the EE system files with these overrides:

$config['third_party_path'] = '/server/path/domain.com/assets/addon_sys/';
$config['path_third_themes'] = '/server/path/domain.com/assets/addon_themes/';
$config['url_third_themes'] = '/assets/addon_themes/';

I typically put all site assets in one folder, so everything is easy to access:

/assets/addon_sys/
/assets/addon_themes/
/assets/css/
/assets/js/
/assets/img/
/assets/low_vars/
/assets/templates/
/assets/uploads/

Answer 2

As I understand it, this is not possible with git-subtree.

Taking the code example from the kernel.org docs:

$ git remote add -f Bproject /path/to/B
$ git merge -s ours --no-commit Bproject/master
$ git read-tree --prefix=dir-B/ -u Bproject/master
$ git commit -m "Merge B project as our subdirectory"

In the read-tree command on line 3 you can only set a single --prefix value (which is where we set the subdirectory of the man project to target for the subtree merge). What you describe would require multiple values with some way to match subtree paths to main project paths.

I do feel your pain with this issue - I've hit the same problem with both client builds using 3rd party addons and with building addons myself. I don't think it's a solved problem so I'd love to hear what you come up with!

As an aside, I've not had issues with checking in symlinks, but then I don't work outside of a mac + Linux environment.

Answer 3

I've just finished getting my setup with git working the way I want. symlinks definitely made things easier but seeing how they're not viable in your case... perhaps just stick with keeping the full themes directory in your submodule and adding it in to the main project after your work is done.

One is apenwarr's git-subtree script

The main difference is that, besides merging the other project as a subdirectory, you can also extract the entire history of a subdirectory from your project and make it into a standalone project. Unlike the subtree merge strategy you can alternate back and forth between these two operations. If the standalone library gets updated, you can automatically merge the changes into your project; if you update the library inside your project, you can "split" the changes back out again and merge them back into the library project.

Though I'm not quite sure how you'd work with only a path of the add-on repo.

Maybe it's easier without the git-subtree script, e.g. following the q-a here:

To start off:

$ git remote add Bar /path/to/bar
$ git merge -s ours --no-commit Bar/master
$ git read-tree --prefix=public_html/themes/third_party -u Bar/master:/themes/third_party

When pulling later:

$ get fetch Bar
$ git pull -X subtree=public_html/themes/third_party Bar master

How are you working with actual third party add-ons whose developers release updates and/or require changes on your own?