Git: all files are in a subdirectory, but they should be top-level

Question

This is the anatomy of a wordpress plugin:

.twitter-plugin
|-images/
|-index.php
+-README

The directory twitter-plugin must be placed in a well known location ( wp-content/plugins ) so Wordpress can scan it and if it founds a README , well it's a valid plugin. Unfortunately when I cd to plugins directory and clone a repository from Gitorious, I get:

.twitter-plugin
+-twitter-plugin
 |-images/
 |-index.php
 +-README

The plugin developer didn't put the files straight in the top level dir, but keeps them in a subdirectory named after the project. This way Wordpress can't find the plugin (it looks for twitter/README , instead there is twitter/twitter/README ). I could overcome this by cloning one directory above (in wp-content instead of wp-content/plugins ) but it feels hackish, has the clear disadvantage that I'll have to ignore all other plugins directories, plus Git will complain that the plugins/ directory already exists (so I'll have to temporary move things around to make it work).

Is there a way to recover this situation? Am I missing something fundamental about git?

At this moment all I think I can do is init a new repository, put the files in, and try to import the history somehow. But this way I won't be able to push to the original repository - right? - because all file paths would be different

My objective is developing the plugin, not just using it. Of course, to develop the plugin, it must be used by some Wordpress installation, so it must be in the well known directory, otherwise my development Wordpress installation won't find it and I won't be able to test my changes

Answer 1

Clone into a location outside your wordpress project, then symlink or copy the correct directory where it belongs, eg:

$ git checkout git@wherever.org:twitter-plugin
$ cd my-wordpress-site
$ ln -s ../twitter-plugin/twitter-plugin ./twitter-plugin

Symlinking may or may not work, since not all PHP functions follow them; if it doesn't, try copying instead. This does mean, though, that you have to copy again when you update the git repo; you probably want to include this procedure in your deployment script.