I’ve been armchair-theorizing for a while about the possibility of using git to manage Ableton’s project files. This fell out of the following facts:

.als files are actually gzipped XML

git hooks and filters can preprocess files as they are committed to the repository

Ableton will happily open .als files that are actually plain uncompressed XML (although when you save it will compress it).

Ah, now I can hear the wheels turning in your head as well: aha! you say, a gitattributes filter can ensure only unzipped XML is committed into the index! Time to usher in a world where I can work in full parallel with my online collaborator(s), only rarely doing tricky merges!

I speculated for a long time before actually trying it, and I know I’m not the only one. Let’s talk about the effectiveness of this solution. But first, the setup. In .gitattributes, add

*.als filter=unzip

and then define the ‘unzip’ operation in your git config:

$ git config filter.zcat.smudge "zcat -f"

$ git config filter.zcat.clean "zcat -f"

This is bash-speak for “never not unzipped.” OK, so .als files in your working tree will now be XML whenever git performs checkout on them, and will be zipped again as soon as Ableton mittengrabbens them.

I mocked up a simple three-way merge scenario where a base project file branched into two variations on a simple saw-wave melody. One branch changed the melody to include grace notes; the other branch changed the melody to imitate the Tokyo Drift song. I also introduced a VST because VST data is stored as gross hex in the XML.

Here’s the melody conflict.