rnsgit is a Ruby command-line program to assist in using Renoise song files with git.
A Renoise song file is a zip file holding all the stuff. The stuff is a mix of text (notable Song.xml) and binary data (i.e. samples).
If you try using git with the xrns file itself git ends up making a copy of that file each time you commit a change.
It would be better to track the unzipped contents. To do that you would need to manually extract those files each time you wanted to record a change. If you decided to change branches or roll back to an earlier version you would have to manually rezip them to get the proper xrns file.
You can do all this by hand, but it’s tedious.
`rnsgit` was created to help. It’s basically a wrapper around calls to `git` and `7z`. You must have both those programs installed to use `rnsgit`.
$ rnsgit init my-colossal-song.xrns # Creates a repo name my-colossal-song
$ rnsgit co "Added superbad vocals" my-colossal-song.xrns # Updates repo and commits the changes
$ rnsgit pin # Creates or updates the local .rnsgit file
With the .rnsgit file in place you can omit passing the name of the song file
$ rnsgit br "faster-version" # Creates a new branch, named, "faster-version" , in the my-colossal-song repo
$ rnsgit st # Show the status of the my-colossal-song repo
Be warned: The code is evolving. Features are missing. In principle you should be able to execute any git command, but not everything will trigger a rebuild or an extraction of the xrns file.
It is possible to lose song changes.
There is some new code being added but it might not yet be in the master branch; it certainly not well-tested. The idea is to compare the mtime of the xrns file to the files in the repo. If the xrns is newer than the repo files then certain actions are needed.
For example, if you have made changes to the xrns but not extracted the files and updated the repo then changing branches or merging might end up rebuilding the xrns while not preserving the most current state.
This is the essence of what makes this tricky. The xrns file is really the only file of interest. The repo, however, knows nothing of the xrns file, only it’s constituents as they have been extracted. Wrapper code needs to handle the correlation of the two in a way that preserves changes as well as movement among different versions.
If you use this please just be aware that stuff can break.