git and max
Hi everyone,
I am a long time Max/MSP user, and newer javascript/php programmer where I learned the value of git (ie. github, versioning)
I've read all the posts I could find here about git and max/msp but they're all older.
I would like to open the discussion here again, so to begin I was wondering who is using git, what issues have you run into, and is merging separate branches still difficult (as I've read it was)?
I still use Max 6, and has Max 7 introduced any features that make it easier/harder to use git?
Thanks!
Mike
I've been using git for repos that contain max files with no issues including merging.
working with git too, but I don't let git merge any maxpat files - resolving conflicts in things like patch chord positions is not possible in any sensible way, imho.... i rather merge them manually. With Max, I commit every baby step in developing a patch, so I can experiment, and then revert. with text-based programming languages, my commits contain much more changes, because I can diff, and therefore have more control over things i actually changed since last commit...
hollyhook, I like your strategy of "commit early, commit often". I've been doing it similarly. At each "feature" I introduce to my patch I commit - with a feature being the tiniest thing you can describe your patch doing.
phil: do you use any special tricks to help? I send this message to max with a loadbang:
;
max sortpatcherdictonsave 1
as I saw suggested in a post here from several years ago. Which keeps the patcher sorted the same and reduces differences, if you do any merging.
I also have been abstracting out parts more - so that each section of my main patch is it's own maxpat file. The idea is that smaller, separate patches will make it easier to merge when I go on to doing that. I don't know if that will be true... But at least my main patcher is cleaner!
I'd be interested in trying to write a diff program that would ignore certain parts of the .maxpat text - such as cord positioning - and instead just check for what objects are included, what is connected to what else, and only things that actually make a difference in the patch we see.
maybe it is just my way to work with max... i keep changing layout of boxes and patch coords all the time, never quite satisfied with how it looks like. that takes anyway too much time, and it generates changes in commits that are "unneccessary". For the diff program it would be crucial to know which graphical information is relevant - box positions may have an impact on processing order in max, box sizes, or patchline points maybe not ...
this is an interesting discussion, @Hollyhook - would you mind please posting a link to one of the max repos that you are using git to track? Thanks!
I use git for my whole life these days. One tip I highly recommend that I used in dev work was to merge by rebasing master *into* your feature branch, and then merge that back on to master. Basically a rebase "replays" your changes over master in your copy, so that merging to master is trivial and any conflicts are sorted out on your feature branch. This keeps master from every getting stuck in merge hell. I would also suggest learning how to "cherry pick".
HTH!
Here's a way to get a git diff for a maxpat without the layout changes:
https://github.com/diemoschwarz/diff-for-max