Git: Maintaining third-party modules consisting of multiple directories

The company I'm working for is using a third-party web application (PHP/MySQL) which can be extended by modules. We need to track our own changes to the core application and to additional modules, keep track of which modules are installed and at the same time maintain the ability to easily update the application and its modules to the latest vendor version.

At this time we're using one git repository containing everything. To maintain updatability we'r开发者_运维百科e using a vendor branch strategy. This works fine for the main app, but pretty soon becomes messy when multiple modules enter the stage.

However I was not able to find a feasible way to manage such a project with git, especially because both git's submodules and git's subtree merging seem to require a subproject to be contained in one directory. But that's not true for most web applications I've seen, as it is with this one which has following directory structure:

app/
  `-code/
      `-path/to/plugin/code
  `--i18n/
      `-path/to/plugin/i18n
  `--assets/
      `-path/to/plugin/assets

So does anybody know how this Problem could be solved without sacrificing too much usability (as submodules do IMHO)

Update:

Please also consider that I'm on Windows Vista and symlinks don't seem to work with Git for Windows.

If your environment supports symlinks, I would recommend the submodule approach, combined with soft links in order to get the proper directory structure.

That way, you get the benefits from:

• a component approach (like this other non-related example)
• a custom directory structure compatible with your application deployment and execution environment.

From the comments:

basically you have two directories structures:

• one resulting directly from a git checkout, with its submodules directories.
• One, manually created to fit the expected structure, with 'ln -s' (or mklink for Windows Vista/Seven) commands in it to link the correct directories from the first structure to the expected place in the second structure.

The OP raphinesse objects:

It would be really nice to be able to just clone the repository and have the required structure to run the app.
Having to recreate the whole hierarchy with symlinks in a separate directory every time someone clones the repository seems like a lot of work to me.

To which I reply:

It can be a script included in the repo itself, that the user would execute in order to generate the correct directory structure. a One-click solution in that case.

The OP raphinesse agrees:

Yeah, I just thought about adding a script which initializes and updates the submodules as well as setting up the relevant links "post-checkout" in the working directory of the main repository (In case the UAC-Prompt doesn't make any trouble). Of course the symlinks set up this way would have to be included in the .gitignore file.