my patches
folder has been a git repo for ages => fearless patching + free offsite backups to github JIC. @TroubledMind, git also provides convenient place to document my patches/changes via commit
messages
shure you can do that, but my way to name the patches saves me one or two mouse clicks
could you explain a bit for a noob how to set this up?
Do you do all your āgitttingā in the terminal, or do you use a gui? Just wondering how your workflow looks.
Is your repo on GitHub public? Iād like to see how it pans out.
if new to git, start with some vids/tuts to get comfortable the basics ā tons of great stuff out there a search away. for the particulars, just navigate to your Rack installation folder, then to projects
and execute git init
from your preferred terminal/command line/shell prompt. youāll find the following most useful: git status
, git commit
, git stash
ā again, tons of helpful references online to get familiar with the particulars
two typical workflows: 1) typical scenario is Iāll commit my projects
repo when I make meaningful changes to a particular patch (or hack something I like), and 2) live patching where I trigger automatic commits for each save during an extended patching session
in the later scenario, I use a file watcher and assign a git commit
with a meaningful commit message. sometimes Iāll add custom text to the message by assigning a set of message fragments to midi events I trigger through a controller prior to saving so the commit includes the generic message fragment plus the triggered fragment, then I reset the custom fragment until triggered again. there are lots of free file watcher tools out there (I pick based on the programming language Iām hacking with). I also like to trigger save via midi controller instead of having to do it manually to keep that from interrupting my creative flow
one more fun tidbit ā since I have my session history via my git repo, later I can iterate through my commit history and execute my session file changes by reloading the appropriate version ā either manually or programmatically ā¦ fun times!
Nice. Iām going to look in to setting this up for myself prontoā¦
Hi @dirkleas
Iām doing a crash course on Git this afternoon thanks to YouTube ā¦ So i have two questions for you:
-
Are you doing all that only locally, or also on Github?
-
Could you please expand on what follows (the app/tool you use, how do you connect it to vcv rack save command, etc.)? ā¦ Iām on Mac, but if you name some windows apps/tools, i will look for Mac equivalents.
Thanks in advance!
Sorry, but Iām gonna have to pick your brains again: is each new (ie fresh, from scratch) patch a separate branch?
Iām a bit new to the git game, and not yet sure of itās capabilities and quirks.
EDIT
Ignore this - Iām working it outā¦
Works brilliantly btw!
If you donāt like command-line, you can always use Github Desktop
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
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.
- Iām generally doing this locally, then later
git push
if sharing/archiving on github - 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
Iām almost always working with the master branch (default) when doing this performance capture
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ā¦
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)
NORMAL GIT PROCESS WITH VCV RACK
So the normal git process to use it with VCV Rack is:
- Create a working directory for your patch and go there with the command line terminal or GUI
- Create a local repo using
git init
in the terminal - Start a new patch in VCV Rack and save it in your working directory
- Use
git status
command to check that git has knowledge of the new file - Add the new file to the staging (intermediate) area using
git add <filename.vcv>
- Use
git status
to check that git already has some file to commit to the repo - Use
git commit -m <"useful_msg">
(ex.:git commit -m "Initial Patch"
) to commit the file to the repo - 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):
- 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ā) - 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:
- Use
git brach <branch_name>
(ex.:git branch test
) to create a new branch - 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
- 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?!
Donāt worry and do this:
- Make some changes to the patch and save it (again no changes in the working directory - the same file and no new folders)
- Use
git add <filename.vcv>
followed by agit commit -m <"useful_msg">
to commit the file to the repo - Use the New File command in VCV Rack to clear the current patch
- Load the file in the working folder ā¦ youāll see that it is the same patch you just saved ā¦ No problem!
Now do this:
- Use
git checkout master
to return to the master branch - Use
git branch
to be sure you are in the master branch (there will be an asterisk beside the name) - Again use the New File command in VCV Rack to clear the current patch
- Load the file in the working folder AND ā¦ TACHAAAAN!! ā¦ The GIT MIRACLE!!!
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ā):
- Use
git branch
to be sure that youāre in the master branch, if not usegit checkout master
to go there - Use
git merge test
to merge the changes youāve made in the test branch with the patch in the master branch - 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?!! So THANKS A LOT @dirkleas for introducing Git to the VCV Rack Realm!!
Hope this can be of help to someone
P.S.: Next Chapter: Automating the Process!
Butā¦
@zero, you can branch as much as you like. There is no negative effect
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.
Thanks. Iām still learning git basics, and wanted to be sure I wasnāt transgressing on āgood practiceā!
It might be code, but we aināt writing code. You might as well call an MS Word .doc file a ācodeā projectā¦