switching a subdirectory managed by git to a submodule

Question

We used to have a local hack of delayed_job in a Rails app, in vendor/plugins/delayed_job. It was installed as a one-time event and checked into git in the main app repo.

Answer 1

I absolutely WOULD NOT RECOMMENDED DOING THIS. You're going to have a lot of fallout since git doesn't know what to do when a directory changes types into a submodule. It would be a significantly better idea to remove the old folder, then make a new one with a different name.

We have a repo used by many people (50+) and decided to make a submodule out of a folder. In order to not have to change some build scripts and the like we did the above change. But this makes git freak out, and so every old branch (pre submodule change) cannot be switched to without first deleting the folder and doing other nonsense, merges with old branches are extremely difficult, and worst of all our automated build system, which is distributed across several machines, totally broke and cannot be manually resolved like individual users can.

So. Just don't do it. Git absolutely does not handle it gracefully.

Answer 2

Assuming that you do not care about the current contents of vendor/plugins/delayed_job in your working tree (i.e. the content that will be checked out as a submodule is already a suitable replacement for the content in your working tree), the normal procedure for converting a directory into a submodule looks like this:

git rm -r vendor/plugins/delayed_job
git submodule add github.com:account/delayed_job.git vendor/plugins/delayed_job

Of course, the GitHub repository URL may vary; for example, you may want to use an HTTP URL instead of the above SSH URL.

But, it seems like you did something a bit different. As best I can tell, you did something like this:

rm -rf vendor/plugins/delayed_job
git clone github.com:account/delayed_job.git vendor/plugins/delayed_job

There are two flaws with this procedure:

1. The plain rm leaves the old files in your Git index.
2. Directly cloning gives you a “subrepository”, but not an official submodule.

Assuming that you do not have any intentionally staged changes in vendor/plugins/delayed_job (you probably do not, since you are replacing it with a submodule), you can clean up the situation with these commands:

git rm --cached -r vendor/plugins/delayed_job
git submodule add github.com:account/delayed_job.git vendor/plugins/delayed_job

Cleaning out all the vendor/plugins/delayed_job entries from the index should fix your “still shows new files” problem. Using git submodule add will create the .gitmodules file which turns the “subrepository” into a true submodule.