How to fix a directory that Git thinks is a submodule

Nuts. I added and committed a directory to my Git repository when the directory itself was another separate Git repository. Now Git thinks it’s some sort of submodule, but it doesn’t know how to deal with it:

$ git submodule update
No submodule mapping found in .gitmodules for path 'blah'

And worse, Git won’t let me remove it:

$ git rm blah
error: the following submodule (or one of its nested submodules)
uses a .git directory:
    blah
(use 'rm -rf' if you really want to remove it including all of its history)

So what to do? This:

$ git rm --cached blah
$ git add blah

In my case I had a situation where there were several Git repositories-inside-a-repository, so I wanted a way to deal with them all:

$ for i in `find . -type d -name .git -print | sed 's#/.git##'`; do 
> echo $i
> rm -rf $i/.git
> git rm --cached $i
> git add $i
> done

(Be careful not to run this find command at the root of your Git repository, of course, or else you will effectively destroy its usefulness as a git repo. )

Separating Configuration from Code in CollectionSpace

For the past few months I’ve been working on a project to migrate a museum’s collection registry to CollectionSpace. CollectionSpace is a “free, open-source, web-based software application for the description, management, and dissemination of museum collections information.”1 CollectionSpace is multitenant software — one installation of the software can serve many tenants. The software package’s structure, though, means that the configuration for one tenant is mixed in with the code for all tenants on the server (e.g, the application layer, services layer, and user interface layer configuration are stored deep in the source code tree). This bothers me from a maintainability standpoint. Sure, Git’s richly featured merge functionality helps, but it seems unnecessarily complex to intertwine the two in this way. So I developed a structure that puts a tenant’s configuration in a separate source code repository and a series of procedures to bring the two together at application-build time.

Footnotes

  1. From the answer to the first question of the CollectionSpace frequently asked questions. []

LYRASIS’ “Reposervice” Setup Pushed to GitHub

Earlier this month published ‘reposervice’ to GitHub. Reposervice is a “self-contained” Islandora installation source tree that is intended to smooth the LYRASIS deployment of repository services between development servers, a staging server and production servers. It is a bit of a work-in-progress at the moment, but others might find it useful as well.

(By the way, if you had looked at Reposervice prior to June 18th, you may have noticed a missing critical element — the Drupal submodule. Not because you couldn’t add Drupal yourself but because the Reposervice clone has relative soft symlinks to the Islandora modules positioned in the top level Reposervice directory.)