I'd like to be able to layer other branches on top of an existing branch, and have those branches be revisioned independently. This would be useful, for example, to allow the binaries for various subprojects to be unified into the same bin
directory. In general a given file would only be present in one layer.
Ideally I guess I would use a unionfs to accomplish this, but it would have to somehow provide a way to access the various .git directories, which are to appearances all subdirectories of the same root. Anyway I think unionfs doesn't actually work? So it seems like a better idea to just maintain a set of symbolic links from the root of the repo to other repositories containg the layers.
I'm considering doing something like this:
- keep each 'layer' in a separate repository
- maintain symbolic links within the master repo to each file which should be layered
- add the symbolic links to the master .gitignore so that they will not be removed when switching branches.
- be completely incompatible with Windows, in order to make it possible to edit files in their location in the root repository. IE use symbolic links instead of just copying the files into the master repo.
It would make sense to track the source commit ID of each layer, so that, for example, files removed from the layer in a subsequent revision can have their symlinks removed from the source repo and be removed from the master repo's .gitignore file.
It seems like such a system would end up working a bit like git submodule
, with the key difference that submodules would co-inhabit the same root level of the repository.
I am wondering if there is already a utility to manage this? I looked into using stg
(stacked git) to implement this sort of structure, but it doesn't seem to be its cup of tea.