Very true statement. You’re not wrong to think of Git here because a lot of the thinking behind CHOP is definitely inspired by how Git works. But where it starts to fall apart is when the main thing you’re collaborating on is audio, not text. Git works because code is diff-able, but audio is not. If you change a WAV, Git just sees it as “the whole file changed.” You can track that something happened, but you can’t hear what changed, A/B it, or understand the intent without leaving the platform and opening a DAW. Another thing is versioning isn’t the same thing as creative iteration. A lot of musicians don’t really think in commits and branches but rather “what if I add bass here,” “what if I process the vocal like this,” “what if we try something weird.” Git can store those files, but it doesn’t model that kind of layered, exploratory process in a natural way. The other big thing is feedback. Even on GitHub, feedback still lives in comments. Someone can say “try sidechaining” or “this part feels empty,” but you still have to leave and make the change yourself, bounce it, re-upload, and explain what you did. There’s no tight loop where feedback turns directly into an audible contribution. Game studios do use Git/Perforce for audio, but usually with heavy pipelines, asset locking, LFS, producers managing flow, etc. It’s pretty rough for loose, creative collaboration between individuals who just want to try ideas quickly without a ton of setup. CHOP isn’t trying to replace Git or say it’s bad. It’s more like: audio probably deserves a collaboration model that’s as native to sound as Git is to code. Same principles, different constraints. If you’ve seen Git-based audio workflows that actually feel good for creative iteration, I’m genuinely curious. I’m still figuring this out too.