-Is there any risk of Git causing issues if I run my Pd patches directly from a Git repo? Is it better to use a separate development repo/directory & then copy the latest version to a separate, non-tracked directory for actual Pd use in concert?

-Is there a way in Git to associate evolving versions of all dependencies in various locations? In my case:

• Pd performance patch directory (with subdirectories containing abstractions)
• ~/Library/Pd (my externals directory)

I suppose I could create a new repo, copy all of my files into it to begin version control, do all of my development there, and then copy/overwrite all files back to their original locations when I want to move from development to performance, but there's got to be a better/safer/neater way to do it all without shuffling files all over the place manually.

For example, suppose you've got "foo.pd" in your project, and when you run it it creates some temporary files "foo.txt" and "foo.wav" in your current directory. It's possible you could accidentally add and commit foo.txt and foo.wav to your git repository. To prevent that you could either copy the project to some other location to run it, or add temp files/extensions to ,gitignore in your repo.

The other thing is that you should make sure you write clear commit messages in Git. Pd patches aren't easy to read, so you'll depend on those messages if you end up having to revert to a previous state.

And thanks also for the notion of writing descriptive commit messages, I can definitely understand the need for clarity, as I wouldn't be able to discern much more than a basic edit in looking at changes in Pd code. Although, as an aside, that thought does make me wonder what would be involved in creating a visual "diff" view of canvases within Pd's gui (or even a more complete built-in Git integration!). Easy for me to speculate, of course, I'm sure it'd be a ridiculous amount of work under the hood for questionable gains.

For example, suppose you open a patch rev1.pd. For each mouse motion, keypress, etc. in the GUI you save a message to a file called diff.pd. (Each message prepended with pd-rev1.pd in this example.) When you're done you save the file as rev2.pd.

Assuming there are no subpatches, you've now got two ways to view your revisions:

1. diff rev1.pd rev2.pd
2. Open rev1.pd, then open diff.pd

Now, you could have also prepended a delay in ms for each message in diff.pd that corresponds to the time elapsed from the moment you started revising rev1.pd to become rev2.pd. If you send those message through [qlist] then you can "play" your diff to watch the changes be applied to arrive at rev2.pd.

So it's not impossible to do. But it would be hard to generalize this to complex patches. Pd currently just uses the memory address of each canvas in the running instance to send messages. Those change each time you run Pd so it's not a robust solution.

Yes, I see how the situation becomes complicated very quickly—my original mental image was of a single Pd canvas with black (unchanged), green (new/modified), and red (deleted) Pd objects, perhaps with view filters to compare versions. But indeed, the question of how to handle canvas resizing, subpatch/abstraction changes, etc. within a single window sounds like a messy one to answer.

Also, the notion of recording every canvas edit poses a useful question to me: what level of detail do I really want/need to save as I develop a project? There have certainly been times when I wanted quick access to an old version of a part of my patch, but if I were to comb through a sequence of hundreds of individual edits to find the right state, I could see this ultimately being more work than simply redoing the work anew. I assume this is the idea behind “commits” in Git, which represent meaningful milestones, so for now I’ll keep studying up & see if I can get a good workflow going that way.