LaTeX-SVG-to-PDF as git submodule

I’ve mentioned previously that I’ve got a large project in $$\LaTeX$$ and while I was using Dropbox as a pseudo revision control and external backup. However, I’ve since been persuaded that a proper revision control system with meaningful commit message is a better way of tracking progress and changes.

So I’ve moved the project to git, set up a remote repository for synchronisation and backup and started making commits. Then I realised that my symlinked makefile was only included as a link in the git repository. This is different to Dropbox, which would synchronise the contents of the linked file.

Instead of just having a symbolic link to a file that might not exist on another computer, I needed another way of including the file properly. I could just drop the file into the git repository, but then it won’t update if I make any changes to the main project files. If I make use a hard link then git will include the file contents, but then it’s possible to make tracked changes in the $$\LaTeX$$ project repository by changing the file in its original repository — and that is just a recipe for confusion.

Instead, it’s probably better to include the makefile repository as a git submodule and then symlink into the sub-repository’s makefile. That way, the exact commit information is included in the parent-repo, but the sub-repo can be updated, changed and branched as needed.

To do this:

cd ~/LaTeX/project/folder
rm makefile # if you already have a makefile in the directory
ln -s LaTeX-SVG-to-PDF/makefile makefile
git commit -m "added LaTeX-SVG-to-PDF as submodule and linked to makefile"

There are a couple of complications to this method:

If you clone a new local repository of the parent project then you also have to initiate and update the submodules to add their contents.

git clone my@server:git/project.git
cd project
git submodule update --init

And you also need to be careful of including changes to the sub-repos. If you git add . && git commit to the parent-repo with uncommitted changes to the sub-repo, then you’ll be telling the parent-repo to use that dirty head on every clone — not good.

If you’ve made changes to the sub-repo, make sure that these are committed (and pushed) before commiting on the parent-repo.