I think this is an interesting proposal. You could do it yourself.
It could be a complementary but independent project to Qtractor.
I don't understand the problem with the "directory" property.
In fact, .qtr files, inside .qtz files, do not include this property.
It is enough to save as qtz, open the file in Qtractor (which will unzip the file) and upload the folder to git.
If you don't want the qtz to be uploaded, add the qtz format to ignore.
The problem I keep seeing is with those plugins that in turn have dependencies (audio samples, sf2, sfz, text files, images...).
Not with the plugins themselves, since inside git you could create the .lv2 and .clap folders with all the plugins from all the projects.
Of course, with lv2 not all plugins are autonomous, some must be installed (calf and carla are the most essential).
But that can be fixed too. If someone doesn't have them installed they should, so you can add in the root Readme of GIT that installing them is an essential requirement.
In summary, the problem is still with the plugins that in turn have dependencies.
Example:
Imagine you want to make a Drumkv1 example with several drum sets for Qtractor with examples of midi tracks already assembled for each set.
No matter how you do it, it simply won't work.
Drumkv1 won't find the samples, and worse still, it won't even tell you the name of the samples that were loaded.
You will have to leave instructions for the person to rebuild the project track by track.
This would be solved if the plugins allowed project-relative paths for their samples.
Fortunately fluidsynth-DSSI does allow editing the path within the project and in presets.
Assembling custom samples in sf2 with Polyphone and using fluidsynth-dssi is going to be my solution for these cases.
In Qtractor plugins it should not include the dependency paths in the compressed part. But I don't know if that can be fixed now due to backwards compatibility issues.
I think this is an interesting proposal. You could do it yourself.
It could be a complementary but independent project to Qtractor.
I don't understand the problem with the "directory" property.
In fact, .qtr files, inside .qtz files, do not include this property.
It is enough to save as qtz, open the file in Qtractor (which will unzip the file) and upload the folder to git.
If you don't want the qtz to be uploaded, add the qtz format to ignore.
The problem I keep seeing is with those plugins that in turn have dependencies (audio samples, sf2, sfz, text files, images...).
Not with the plugins themselves, since inside git you could create the .lv2 and .clap folders with all the plugins from all the projects.
Of course, with lv2 not all plugins are autonomous, some must be installed (calf and carla are the most essential).
But that can be fixed too. If someone doesn't have them installed they should, so you can add in the root Readme of GIT that installing them is an essential requirement.
In summary, the problem is still with the plugins that in turn have dependencies.
Example:
Imagine you want to make a Drumkv1 example with several drum sets for Qtractor with examples of midi tracks already assembled for each set.
No matter how you do it, it simply won't work.
Drumkv1 won't find the samples, and worse still, it won't even tell you the name of the samples that were loaded.
You will have to leave instructions for the person to rebuild the project track by track.
This would be solved if the plugins allowed project-relative paths for their samples.
Fortunately fluidsynth-DSSI does allow editing the path within the project and in presets.
Assembling custom samples in sf2 with Polyphone and using fluidsynth-dssi is going to be my solution for these cases.
In Qtractor plugins it should not include the dependency paths in the compressed part. But I don't know if that can be fixed now due to backwards compatibility issues.