Using Git to Manage An iTunes Library?

Solution 1:

The main drawback is disk space. The repository itself will take the same amount of space as the set of "checked-out" files. This means when you clone the repository your collection will basically take twice as much disk space.

Worse still, even if you delete files you no longer want, there will still be copies in your repository, taking up space.

You might want to look at synchronisation tools like unison which is designed for two-way synchronisation of files across multiple machines.

Solution 2:

Can you think of any reasons why this would be a bad idea?

Git is not suitable to such usage.

The way git works is it keeps the repository data in .git/ folder. With text, this is a non-issue, it can be compressed easily, and the files are small - the repository might be a megabyte or two.

Compressed data (MP3s, JPEGs etc) cannot be compressed by git further, and since you effectively need to store two copies of the data, this will double the disc-space required (one for the files, one for the repository)

Text is tiny, and compressible, and importantly you can easily "diff" between two revisions - only storing the changes. If you only change one line, git only stores that one line (and any associated metadata, like the commit message)

Binary files are hard to diff, so say you modify the tags on 100 files (say, to add artwork, or change a genre), git will store a new copy of those files in it's .git/ directory. Say you then strip out all the comments from your music's metadata, git will then store another complete copy of your files! This will mean your repository will now be over twice the size of your actual files (say you had 10GB of music, your music folder will now be over 30GB)

As I said, git isn't suited to such things - it's aimed at tracking source code, with lots of little changes to text files, not big binary files. There's not much point in keeping a revision history of your music library, when all you need a syncing tool.

Since you're considering using git, I assume you're happy enough with command line tools, so I would suggest looking into using rsync to sync your iTunes library between machines. The biggest problem, as joshhunt mentioned, is iTunes uses absolute paths to media files, so the iTunes Library.xml file contains things like..

<key>Location</key>
<string>file://localhost/Users/dbr/Music/iTunes/iTunes%20Music/65daysofstatic/Hole/01%20Hole.mp3</string>

If you use the same OS, and same username on all machines, this is a non-issue - keep the files in the same path and it should work fine. If not, things get a bit more complicated..

You could write two scripts, one that updates the paths from machineA to machineB, and vice versa. You could move your iTunes Library to somewhere like /User/Shared/Music/ so the paths are the same (although this may not work for OS X -> Windows)

There are some utilities to sync iTunes Libraries between machines, such as..

• myTuneSync ($19.95USD)
• Syncopation ($24.95USD)
• SlingShot ($29.99USD)

(from this article)

Solution 3:

I'm not sure whether Git has problems with the sizes of files in a music library (it doesn't perform well with large files, but I'm not sure exactly how large), but Joey Hess wrote a program called git annex for dealing with this kind of use case.

Solution 4:

Version control systems in general are designed for handling text files. Every time you update a binary file it needs to create a completely new file as opposed to just storing a delta.

How this translates to real-world use is that your library would use a lot of disk space if you changed it regularly.

If you are only talking about the library file itself, this might be OK.