DeadAscend
DeadAscend copied to clipboard
Use git submodules for extensions
Now instead of manually cloning them in the extensions
folder,
you can run git submodule update --init
.
You can also define what commit/branch/tag to track if the tip of the master branch is not suitable for production.
This is just a suggestion, feel free to reject it if you prefer to keep "real" repositories in extensions/
(especially if you do your dev work for those libraries there directly).
Thanks! Sorry for the conflict :) I've tried to find a solution for exactly this scenario. The problem is that I'm also maintaining both dependencies (Qak, QtFirebase) so I have stuff symlinked to save space. So it's because of my development I haven't done this.
Maybe I should have some kind of dev_qak
/ dev_qtfirebase
check or something - still a bit undecided :)
Yes, as I mentioned if your dev workflow requires those to be real git clones (or symlinks to git clones) instead of submodules, it's a valid reason to reject this change. Submodules have pros and cons, and in the case of libraries that you maintain yourself, the cons may outweigh the pros (e.g. if you want to always test the latest code of those modules or even uncommitted stuff, having real clones/symlinks is much better).
@akien-mga :+1: I like your approach. In my opinion it simplifies things.
@Larpon This pull request is nearly one year old, what are your thoughts about it? Not sure if I understood your way of working correctly, so maybe this would fit your needs:
- a git submodule is just a normal git repository, by default it's state is 'detached HEAD' (pointing to a specific commit)
- you can checkout any branch and work on it
- e.g. a dev branch is what you use to develop/test new features/bugfixes etc.
- merge your changes from dev to master
- update the submodule reference and push your changes
Git 1.8.2 added the possibility to track branches, so instead of referencing a specific commit, your directly reference a branch. .E.g it would always use the latest and greatest from the master branch.
@kratz00 - submodule checkouts still require HDD space? Which I'm practically out of (I have to move things around already as it is). I'm developing my next adventure game which, right now, can go to 8K resolutions so the development data files take their toll on the space.
Since I'm the maintainer of both dependencies (Qak, QtFirebase) I have have many projects dependent on them - so the single most easy thing for me to do in this situation is to have symlinks pointing to the projects. Also the Firebase C++ SDK from Google is ~800 megs or so alone.
I'm not against using sub-modules - it's just that it complicates my development circle locally
@Larpon Thanks for sharing your thoughts. Looks like there is no easy way to make both parties happy :disappointed: The best solution is probably the following approach (item 3 from the link):
sudo mount --bind /path/to/main/repo relative/path/to/submodule
But I feel it could be annoying to run the mount command all the time.