Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use git submodules for extensions #6

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

akien-mga
Copy link
Contributor

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).

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.
@Larpon
Copy link
Owner

Larpon commented Apr 9, 2018

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 :)

@akien-mga
Copy link
Contributor Author

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).

@kratz00
Copy link
Contributor

kratz00 commented Mar 19, 2019

@akien-mga
👍 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.

@Larpon
Copy link
Owner

Larpon commented Mar 19, 2019

@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

@kratz00
Copy link
Contributor

kratz00 commented Mar 19, 2019

@Larpon
Thanks for sharing your thoughts.
Looks like there is no easy way to make both parties happy 😞
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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants