Jim DeLaHunt
Jim DeLaHunt

Reputation: 11395

One working tree, jointly managed by multiple repositories?

I am wondering if there is a way to version-control a directory tree jointly between multiple (at least 3) Git repositories.

Here is a simplified version of my directory tree. In real life, it's the web-serving directory for a Drupal or Joomla web site.

root/
    index.php   # code, managed by application repository
    configuration.php  # secrets, e.g. database password
    uploads/    # contains user-supplied data
    temp/       # directory of temporary files, not archived
    attack.php  # attack code or data, unwanted, should be detected

index.php represents the code of my web application. Only developers contribute to it. We want it version-controlled. We want to rely on Git for deployment to the staging and production servers.

configuration.php represents the configuration of the web app as deployed. It contains values which differ between the staging and test releases of the app, e.g. the name of the database the app should use. It also contains values which are secret, e.g. the password to the database. I don't want those secrets in the application repository. Instead, the application repository has a placeholder copy of this file, with innocuous values. I think I want a second repository, hosted on the server but with limited distribution, to manage this file.

uploads/ represents files, and directory trees, containing user-supplied data: their blog posts, their images, their shared files. These files should not be added to the application repository. However, I might want to have a separate repository of user-supplied data to track these. I could back them up, I could use the repository to move them to a different server. I want to notice if an attacker adds files, e.g. with unexpected filename extensions, to this directory.

tmp/ represents a directory of temporary files generated by the application as it handles user activity. It might be a cache. I don't want these files in any version control. However, I do want to notice if an attacker adds files, e.g. with unexpected filename extensions, to this directory.

attack.php represents both new files, and changes to application files, which are added by a malicious attacker. I want to be able to detect that these have appeared. git status is great for this, if the repository has the right content.

It's easy for me to see how to manage this directory tree with a single app repository. set up this directory tree with a git dir elsewhere. I can sprinkle '.gitignore' around, say, to ignore the contents of uploads/ and tmp/. I can have the app repository ignore configuration.php.

I don't see how to set up a second repository to manage configuration.php, and overwrite the innocuous values in the app repository's copy. I don't see how to set up .gitignores which will tell the app repository to watch index.php and ignore uploads/, while telling the user data repository to do the opposite.

The underlying obstacle seems to be that Git assumes that the working tree belongs to only one repository, and I'm trying to get multiple repositories to share it. So, is there a way to share like this, practically, with Git?

Question Multiple repositories in one directory is similar. I think someone claims this can be done with Subversion. I don't see any of the answers saying it can be done with Git. Especially, an answer which points out you can specify --git-dir and --working-tree parameters to many Git commands, doesn't talk about how to handle differing .gitignore needs.

Question Is it possible to manage multiple repositories coherently? has an answer which mentions Repo, which in turn mentions Gerrit. That is interesting, but has anyone used them to set up a structure like I'm after?

An alternative to sprinkling .gitignore files across the working tree, is to list paths in the $GIT-DIR/info/exclude file for each repository. This lets each repository ignore what it wants to ignore. But I'm concerned that the contents of these exclude files won't themselves be version-controlled, and might not get passed on to developers who are working on the app in their own repositories.

What approach do you recommend?

Upvotes: 0

Views: 62

Answers (1)

VonC
VonC

Reputation: 1324208

Aggregating multiple repo in one main repo is the job done best by:

For a file with confidential or environment specific data, you should use a content filter driver (see this answer) which would, on checkout, automatically generate the file with the appropriate content.

Upvotes: 1

Related Questions