Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Separate repos #758
I would like to propose the idea of having all of the runtimes in separate repositories. Then users could simply clone or submodule the specific runtimes to their project, and no copying or archive downloading is necessary. And this would have the enormous advantage of letting people update their submodules when you push out an update, rather than repeating the current workflow for using specific runtimes from here.
If you did so, you could even continue to maintain this repo by replacing all of the runtime folders with submodules pointing to them, and people using this repo wouldn't actually have to do anything different (except cloning with the
I would even go so far as to guess that nobody actually "uses" this repo as it is, by which I mean clone or use as a submodule. Everybody probably just downloads it and takes the folders they need, which is a rather outdated workflow for post-2010. Since git does not support partial clones, the current workflow for using this repo is actually pretty bad for people used to more... "modern" ones (I'm not trying to be mean with that word; I am just addressing the elephant in the room).
Say I want to use spine-love, which requires spine-lua as well. This repo is
In fact, spine-lua could just be a submodule of spine-love as well, which would completely supersede my recently-opened #757. Then people that clone/download/submodule spine-love would have all dependencies, and no unnecessary files.
Just think about it---I realize this would be a small change in your process. You would of course be able to keep all the folders exactly as you have them right now on your systems, but you would have the additional step of committing to this spine-runtimes project when you commit to their individual repos.
We've considered submodules before. However, given my (vast) experience with submodules in previous (bigger) projects, I'm not sure entirely I'm in favor of this change.
It does indeed impact our workflow quite a bit:
I do strongly agree that copying sources around is not a good solution. However, as you said in your other issue, users could simply clone the entire repo (130mb isn't a big deal in modern workflows :)), then symlink the folders locally as needed.
We have to think about it. Ultimately it's @NathanSweet 's call.
I can see the pros and cons with both approaches. I personally dislike the overhead of dealing with many repos, especially since we version the runtimes together. 2-3 is OK, but 18+ is just too much. It adds lots of "updated submodule" commit noise and makes dealing with the runtimes as a whole terribly annoying. We could write scripts in an attempt to make it more manageable, but that gets messy. I think we'll stick with the monolithic repo for now.