Basically that's what Git-LFS does; it takes the SHA of the file, stores it in the git version of the file, and then stores the contents next to it. It's all transparent and works pretty well.
Hmm, but the point of Git-LFS is to store large files outside the CAS so that they don't burden operations like `clone`. And Git-LFS does lots of magic.
Maybe to achieve what I've laid out, I really would need to write a Git extension a la Git-LFS. But then vanilla Git wouldn't be able to make full use of it, which undermines the purpose of using Git in the first place.
As an alternative, maybe I just commit the darn audio files to the repo.
• In relative terms, audio files grow smaller ever year.
• Large repository size isn't as critical for a music composition tool as it is for perpetually maintained software source code.
• I'm imagining a tool to prune edit history which would consolidate commits and potentially garbage collect audio files that become unreferenced.
I wish there was a way in vanilla Git to just associate a CAS object containing arbitrary bytes with a commit object, though.
I agree that decoupling from Git has its benefits, and I've built a tool[1] that seems to meet some of your needs above. The idea is to save binary data in a separate content-addressed store and have Git track references to specific files in said store. If you check it out, I'd be happy to hear what you think!
What exactly is the issue? Why do not you just use submodules? Or you might want to associate the SHA-1 of commits to files outside git? Ugh, I need sleep.
