HowTo: Set up a github repository for your VCV patches

Plugins & Modules
11

If you are reading this thread and, like me, you found interesting the proposal of @dirkleas on the use of ‘git’ to manage the different versions of your patches, and it turns out that you are in Mac OS X 10.11 or later, you will have some problem when trying to use ‘git’ after installation, due to Apple System Integrity Protection (SIP) … So here are two solutions i’ve found in the Net (1) (2) to solve that (personally i used the second):

Solution 1:

1. Open the terminal
2. Type nano .bash_profile to open the bash_profile in nano (a terminal editor)
3. Copy/Paste this code: export PATH="/usr/local/bin:$PATH"
4. Exit and Save the bash_profile: Ctrl + X, and type `Y’ to save file change.
5. Refresh the bash shell environment: source ~/.bash_profile

Solution 2:

1. Open the terminal
2. Type nano .bash_profile to open the bash_profile in nano (a terminal editor)
3. Copy/Paste this code: export alias git='/usr/local/bin/git'
4. Exit and Save the bash_profile: Ctrl + X, and type `Y’ to save file change.
5. Refresh the bash shell environment: source ~/.bash_profile

Hope this helps somehow

12

Branches are used mainly to try code modifications or develop parallel versions of an already working code without efecting the master branch (i.e.: code) of the project … Once those modifications are working as expected we can merge the modified code to the master branch … So any new fresh patch is suposed to be a new project/repository.

13
  1. I’m generally doing this locally, then later git push if sharing/archiving on github
  2. tooling depends on what else I have going on – typically hack a few lines of code/script to automate (e.g. node.js + node-watch + child_process, golang + fsnotify + os.exec, etc.) – then I midi trigger via keyboard maestro on macos, et’al to map midi-to-keystrokes in rack (many keyboard macro apps support midi on rack supported platforms)

a minor constraint is git timestamps precision only supports down the second – if I need more precision, I add a guid to my commit message and store related detail elsewhere (e.g. sqlite3, file system, etc.) – most of the time, second-level precision is more than reasonable, especially when I’m triggering save based on performance touchpoints

14

I’m almost always working with the master branch (default) when doing this performance capture

1 Like
15

What are the ramifications/consequences of using a single (empty) MASTER with each branch containing versions of one patch?
The advantage is that Rack only has to look in one place for patches.
It’s not the way it’s used in code projects - but this isn’t a code project…

16

In fact IT IS a code project … If you open any .vcv file with a text editor (notepad (win), textedit (mac)) you’ll see that it is a code file that includes all the info about all the modules and its parameters + other info in the patch (i think its a .json file)

So let’s staaaaaart! … Hey guuuuuuuuuuyssssssss! (and gals) :sweat_smile::joy:

NORMAL GIT PROCESS WITH VCV RACK

So the normal git process to use it with VCV Rack is:

  1. Create a working directory for your patch and go there with the command line terminal or GUI
  2. Create a local repo using git init in the terminal
  3. Start a new patch in VCV Rack and save it in your working directory
  4. Use git status command to check that git has knowledge of the new file
  5. Add the new file to the staging (intermediate) area using git add <filename.vcv>
  6. Use git status to check that git already has some file to commit to the repo
  7. Use git commit -m <"useful_msg"> (ex.: git commit -m "Initial Patch") to commit the file to the repo
  8. Use git log to check the commits

So you have already your initial patch in the git repo of your working directory.

USING ONLY THE MASTER BRANCH FOR THE PROJECT (PATCH)

Now if you want to work all the time with the same file (i.e.: no separate versions) you continue (1) working with your patch, (2) save it from time to time, (3) use steps 5. and 7. above (with appropiate msg to each commit) to commit your file to the repo, work again in it, and so on until you finish your project. And if for some reason you want to revert to some previous commit (kind of version):

  1. Use git log to see the list of all your commits and its asociated commit_number (the long line of numbers and letters right to the word ‘commit’)
  2. Copy the commit_number of the commit you want to go back to, and use git checkout <commit_number>

Now if you reload your patch you’ll see that the patch is in the state you save it in that commit … And if you use git log you’ll see that any later commits have dissapeared … BUT DON’T WORRY, because they are still there in the repo … So to go back to your latest commit use git checkout master (use git log to check that it is so) … So if you now reload the patch you’ll see that it is the last commit you made (i.e.: the last “version”).

USING NEW BRANCHES FOR CHECKING NEW THINGS/MODULES

Now let’s say that you want to keep your initial patch as it is, but want to check some new things, or new modules without “corrupting” the actual patch … Then you’ll need to create a new branch:

  1. Use git brach <branch_name> (ex.: git branch test) to create a new branch
  2. Use git branch to check that the new branch has been created

After that you have an exact copy of the master branch in the new branch

  1. Use git checkout <branch_name> to go to the new branch

Now you are in the new branch and any changes you do to the patch will effect only this branch … BUT NOTE that it seems that nothing has changed in the working folder: i.e.: the initial file is there and no sign of new folders with a .vcv file in it … WHAT’S HAPPENING?! :scream:

Don’t worry and do this:

  1. Make some changes to the patch and save it (again no changes in the working directory - the same file and no new folders)
  2. Use git add <filename.vcv> followed by a git commit -m <"useful_msg"> to commit the file to the repo
  3. Use the New File command in VCV Rack to clear the current patch
  4. Load the file in the working folder … you’ll see that it is the same patch you just saved … No problem!

Now do this:

  1. Use git checkout master to return to the master branch
  2. Use git branch to be sure you are in the master branch (there will be an asterisk beside the name)
  3. Again use the New File command in VCV Rack to clear the current patch
  4. Load the file in the working folder AND … TACHAAAAN!! … The GIT MIRACLE!!! :crazy_face:

BUT THERE’S STILL MORE, SO DON’T LEAVE YET

Let’s say that you’re satisfied with the changes you’ve made in your new branch and you want them to be added to the patch in the master branch (let’s assume that the new branch is called “test”):

  1. Use git branch to be sure that you’re in the master branch, if not use git checkout master to go there
  2. Use git merge test to merge the changes you’ve made in the test branch with the patch in the master branch
  3. Clear the patch and load the file in the working folder … TACHAAAAAAN!!! … More Git Miracles!!!

NOTE: Don’t forget that you can always go back in commit history with git checkout <commit_number> … And keep in mind that any branch you’ve created will be there until you remove it with git -D <branch_name>

Isn’t Git wonderfull?!! :heart_eyes: So THANKS A LOT @dirkleas for introducing Git to the VCV Rack Realm!! :clap:

Hope this can be of help to someone :pray:

P.S.: Next Chapter: Automating the Process!

1 Like
17

But…

18

@zero, you can branch as much as you like. There is no negative effect :slightly_smiling_face:

Branching in git can be a complex subject, even among software professionals. It doesn’t have to complicated at all for this application.

If you like having a “one branch per patch” workflow, go for it! You’ll have good isolation between projects. If you decide to bring those branches into master at any point your options are open.

If you like the idea of keeping it very simple and only using the master branch, great! Your patches will be well looked after, and you have the option to branch at will.

1 Like
19

Thanks. I’m still learning git basics, and wanted to be sure I wasn’t transgressing on ‘good practice’!

20

It might be code, but we ain’t writing code. You might as well call an MS Word .doc file a ‘code’ project…

21

So sorry to have tried to clarify what kind of files are we dealing with, and why they are able to be used with Git … So sorry to have thought that you would be interested in it … But don’t worry it will not happen again.

Thanks anyway for the comment! … Good luck in automating the process :pensive::man_facepalming:

22

I was extremely interested in the rest of your comment…
Linus wrote git as ‘a content management and tracking system’ - it is specifically NOT only for code.
Certain parts of it are certainly geared towards code development, but it suits our purposes just fine. I am unlikely to want to merge or rebase a patch - I’m not certain that a vcv patch would necessarily survive such an operation in the state required - but a trail of commits and the ability to branch is invaluable.
My apologies if you misread my tone.

23

Thanks A LOT for the info @dirkleas! … Currently learning Go thanks to your suggestion about golang + fsnotify + os.exec.

I like Go A LOT (concurrency, simplicity, etc) … It gets me to the past where programming and hacking code to learn from others was a real delight…until i had to use it to earn some money :sleepy: … Anyway a beautiful language to get back to programing after many years, so thanks again.

So time to share my little spare time between VCV Rack and Go (+ Git inbetween the two), and enjoy both, as both are my total joy right now :hugs:

2 Likes
24

Just two quotes from opensource.com and quora.com:

Does git handle binary files?

Keep in mind that a binary blob is different from a large text file ; you can use Git on large text files without a problem, but Git can’t do much with an impervious binary file except treat it as one big solid black box and commit it as-is. … You git commit it once, adding a gigabyte to your repository’s history.

Can we store binary files in git?

Git can store binary files , but you lose a lot of the functionality when you do so. As an example, if you store an .xlsx file in git , it won’t be able to do any intelligent merging of changes to the file , which may undermine the usefulness of storing the file in git.

So we’ll never be grateful enough to @Vortico (aka Andrew Belt) that he decided to use text code files to save our patches and not binaries, so now we can use Git to manage our versions/experiments in a clear/friendly environtment as Git is!

And who knows if in the future, and thanks to @dirkleas introducing Git here as a version control system for our patches, there not will be a VCV Rack integration with Git (which would be a really wonderful feature for VCV Rack!)

Have you tried my short tutorial above to be certain that “a vcv patch would survive or not to such an operation in the state required”? … Or you’re only guessing?

Don’t worry about, life is as it is! :wink:

1 Like
25

‘I’m not certain’ means I’m guessing - and my guess is that some would survive but that some would not: there is likely to be conflict I feel. No, I’ve not tested this - but as my workflow is unlikely to need merging I haven’t dedicated any time to it. I’d certainly be interested if someone were to perform a series of tests though. The ‘binary blob’ discussion is a bit of a strawman - I’m in total agreement that git works best on files stored in text format. It’s just agnostic as to the type of text file - there’s a charming little git tutorial on YouTube which uses writing a poem as it’s example.

26

You know, it would be Pretty Nice if there was a way to hide the versioning under the covers, so to speak – so each time you clicked “Save Patch” instead of “Save Patch As…”, you’d get a dialog with a default commit message in place already, which you could of course edit to what you’d prefer. Would have to think about how to handle versioning in the “Open…” dialog, since the versions aren’t actually present in the filesystem. I suppose a secondary “which version” dialog could work.

Not that I am expecting Andrew to do this…!

27

Hi @joe.mcmahon

  1. If you’re a programmer look at this and this posts from @dirkleas above to get an idea about how this can be made and the tools to use for doing it … Basically it would consist in a file watcher able to trig a command each time a file or directory changes, so that everytime you “Save” or “Save as…” your patch, it triggers a “git add + git commit -m <“useful_msg”>”

NOTE: Right now, i don’t know if a file watcher could trigger an executable, but if it is possible, it could trigger a GUI App for the user to fill the data, create branches, open diferent versions, etc., before triggering the required command.

  1. If you’re not a programmer you will have to wait for someone that can explain clearly how to do it and the exact tools to use in any VCV Rack supported system (personally i have this task in my todo tasks for when i have some time).
28

if there’s interest I could quickly put together all the pieces so it’s trivial to turn on/off – lemmie know

1 Like
29

Personally i’am totally interested in seeing how you do it! :upside_down_face: (although I know myself and I know that i’ll try to make my own version later … if you don’t mind, of course! :crazy_face:)

But let’s see what others say about your proposal!

P.S.: BTW, i’ve seen that there are some GUI and CLI toolkits for Golang!

30

I’ve given up on titles years ago, I always save my projects with date and style, like “20190416rock”. I would never find stuff in the endless pile of crappy working titles. I usually remember roughly when something was made. That’s the same format, no matter what kind of software I use.
Works for me.