views:

34

answers:

1

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.

A: 

I'd like to be able to layer other branches on top of an existing branch, and have those branches be revisioned independently

This is definitively what a submodule is for.

The trick is: you want several submodules declared all in one common path within your main project (like <project>/bin).

It is not possible, at least not in a cross-platform way, so that leaves you only with the question: "is this layout absolutely necessary?".
For instance, having all the binaries in one directory strikes me more as a deployment issue, rather than a source management issue.
I.e: you should be able to develop with binaries isolates in their respective directories, while testing your deployed app with binaries in one directory.

VonC
In some circumstances, for instance in situations where interpreted code is being edited on a deployed system, this isn't necessarily an option. My immediate goal is to be able to edit various modules in my .vim directory without having to a) keep everything in one repo || b) switch to a different run environment and interrupt my workflow in order to spend 10 minutes making a fix or adding a feature. Perhaps vim is a bit atypical in its tendency to mix components from different modules (aka vimscripts) in the same directory set, but that is one example of a system that works this way.
intuited
@intuited: understood. Interesting case, but I have no immediate solution there.
VonC