After reading the previous section, you might have reasons not to copy the history of your subproject directly into a subdirectory of your application. After all, anyone can see that the two projects are separate: your application depends on the library, but they are obviously two different projects. Merging the two histories together doesn’t feel like a clean solution.
There are other ways of approaching the problem that you might like better. Let’s look at one obvious method: simply git clone the subproject into a subdirectory by hand every time you clone the main project, like this:
git clone myapp myapp-test$
git clone ~/git.git git$
echo git >.gitignore
This method is reminiscent of the partial checkout method in Subversion or CVS. Instead of checking out just a few subdirectories of one huge project, you check out two small projects, but the idea is the same.
This method of handling submodules has a few key advantages:
The submodule doesn’t have to be in Git; it can be in any version control system or just be a tar or zip file from somewhere. Since you’re retrieving the files by hand, you can retrieve them from anywhere you want.
The history of your main project never gets mixed up with the history of your subprojects. The log doesn’t become crowded with unrelated commits, and the Git repository itself stays small.
If you make changes to the subproject, you can contribute them back exactly as ...