Using Git to Manage An iTunes Library?

"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."

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.

You might be thinking of something more along the lines of rsync.

"The disk space problems described above are certainly true. But there are two separate problems. One is that you have to store the repository and the data, so each file is stored 2 times. The second problem is that every time you change your metadata a whole new copy of the music gets stored, so gradually you end up storing your music N times, where N continually increases. The first problem might be OK, the second is a real drag.

So it's interesting that while Git suffers from the second problem, Subversion doesn't. Its diff algorithm works on binary files, so you only store what changes. That's why I use Subversion for my photos, very similar to your use case, and I'm very happy with it.

Here's a log that illustrates the problem. Note that Subversion actually stores three copies: one in the repository, one in the .svn directories in the working copy, and the working copy itself. However, it doesn't use any extra space as I change the metadata.

mat@Winter:~/temp$ git init repo
Initialized empty Git repository in /home/mat/temp/repo/.git/
mat@Winter:~/temp$ cp -r light_and_magic/ repo/
mat@Winter:~/temp$ cd repo/
mat@Winter:~/temp/repo$ du -hs .
101M .
mat@Winter:~/temp/repo$ git add light_and_magic/
mat@Winter:~/temp/repo$ git commit -m 'First commit'
...
mat@Winter:~/temp/repo$ du -hs .
191M .
mat@Winter:~/temp/repo$ id3v2 -a 'ladytron' light_and_magic/*.mp3
mat@Winter:~/temp/repo$ git commit -a -m 'changed metadata'
...
15 files changed, 0 insertions(+), 0 deletions(-)
mat@Winter:~/temp/repo$ du -hs .
282M .
mat@Winter:~/temp$ svnadmin create repo
mat@Winter:~/temp$ svn co file:///home/mat/temp/repo working
Checked out revision 0.
mat@Winter:~/temp$ cp -r light_and_magic/ working/
mat@Winter:~/temp$ svn add working/light_and_magic/
...
mat@Winter:~/temp$ svn commit -m 'First commit' working/
...
mat@Winter:~/temp$ du -hs repo
91M repo
mat@Winter:~/temp$ du -hs working/
201M working/
mat@Winter:~/temp$ id3v2 -a 'ladytron' working/light_and_magic/*.mp3
mat@Winter:~/temp$ svn commit -m 'changed metadata' working/
...
mat@Winter:~/temp$ du -hs repo/
91M repo/
mat@Winter:~/temp$ du -hs working/
201M working/"

If I recall correctly, iTunes libraries stores the locations to music as absolute paths, not relative to the library file. This would cause problems if the music was being stored in two different locations on the computers.