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:

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 ...