Renaming Conventions: Version Control System

A discussion on renaming conventions took an interesting branch into implementing a version control system. Prompted by @dirkleas I’ve set up a git repository inside my patches folder which I’m administering via Gitkraken.
I’m only just beginning to explore the possibilities - and I’m also pretty green with git anyway - but it opens up previously only dreamt of functionality.
Gitkraken is enormously over specced for a fairly straightforward git project - would be a great boon to all if some enthusiastic coder took it upon themselves to produce a GUI specifically for the task.

Yeah, I could use the terminal, but…

My workflow:

Start with an empty patches folder - move old patches to a folder called old patches?

Initialise a git repo in patches.

  • make sure you’re in the MASTER branch before starting on a new or imported patch

  • start a new branch - a meaningful name is useful.

  • either

    • save a new patch
    • import an old patch from old patches
  • stage and commit this patch to the new branch

  • continue to adapt your patch

  • save, stage & commit at appropriate points

    • leave useful notes in the commit summary as you do
  • go back to any save point

  • start a new branch at any save point

I commit all of my patches to Git, and mirror them in a private Github repo. I don’t usually branch much, my workflow is pretty linear, so all I have is one file (or folder, if working with other assets like .wavs) per project, and I commit on top of master every time I change them. When I want to work with multiple versions of a patch, I keep 2 or more copies of the project file, but it’s quite rare for my workflow.

The main reason I have this linear workflow is that Rack patches aren’t really designed to be easy to merge in the Git way, and Rack doesn’t really have ways to copy-paste between patches like a DAW would, so if you have diverging versions of a patch it’s hard to converge them again.

I don’t regard branches as candidates for merging, but as different creative directions…

Thanks @zero for mentioning this thread here I had not found this one.

My main problem with working with git that way, or any other SCM for that matter, is that it is even more steps than just renaming a patch.

For a few other programs I just monitor the project directory and have the script auto-commit to Fossil on changes to to the files. Have not tried this with Rack yet as I have no idea what and when it writes to the files. Only on saves?


Rack makes an autosave of the current patch at user definable periods - the file to look at is ~/.Rack/settings-v1.json on my Linux box. This is saved to autosave-v1.vcv so doesn’t trouble your original saved (or unsaved) patch. The period can be set to 0 if you want to turn that feature off.

I agree that working with git & Rack can be a little cumbersome - even if using a GUI for git - but there is no reason that someone couldn’t whip up a little script to take care of it. I’d be interested to see any solution you might come up with…