Submodules in Pull Request

Sponge Sponge Development
1

Hey, just a quick question that nobody answered on IRC and I couldn’t find documentation on elsewhere.

When developing Sponge and preparing for a pull request, what’s the standard workflow for handling the submodules with Git? I realise for me to test compilation and use my implementation I must have my updated version of the API/Common to compile SpongeForge/SpongeVanilla, however if I change the .gitmodules file to point to my fork of the API/Common then when I make a pull request it will include those changes. If I revert them back to the original submodules but change the branch to my feature/(name) when making a pull request it will not compile via travis unless the API changes are pulled first, etc.

It can get quite messy thinking about it and I’ve not found much to go on. If anyone who’s already developed for Sponge or a Sponge developer could give a standard process, it would be nice. I understand many people will take this as obvious but submodules for me are a new area; I’ve never really had a project depend on them.

Thanks for the time, if you attempt to answer this, anyway!

1 Like
2

I’ve found good information on it in this article: Git - Submodules

Basically, you can put the submodule configuration pointing to your SpongeAPI repo into .git/config:
git config submodule.SpongeAPI.url MY_REPO_URL
This will force git to use your own repository without actually changing it for everyone else.

3

As far as I understood the question, it’s more about the process and how to go about it when you have changes in more than one module/repository with some kind of dependency between the changes and at least one of the repos is a submodule of another.

Specifically @cossacksman made a change/commit to SpongeForge and/or Vanilla which doesn’t work on its own, but also required them to make a change/commit to SpongeCommon. So it affects at least 2 repositories now, one of them a submodule. That is, of course, if I understood it correctly.

4

OK, more extensive guide here:

Step 1: Fork main repository and Submodule repository to your own github user

Step 2: Check out main repository
git clone https://github.com/YourName/SpongeForge

Step 3: Change your local submodule configuration, so that you can actually work in the submodule
git config submodule.SpongeCommon.url https://github.com/YourName/SpongeForge

Step 4: Init the submodule
git submodule init && git submodule update

Step 4.1: You also need the SpongeAPI submodule here, but if you don’t modify it you don’t need to fork/redirect it, so just go to the SpongeCommon dir and do git submodule init && git submodule update

Step 5: Make changes! Yay!

Step 6: Commit the changes in the submodule as if it was a normal git repo

Step 7: When doing a git diff in the main repository, You’ll notice that there is an entry like this (Example from article):

Submodule DbConnector c3f01dc..d0354fc:
  > more efficient db routine

That tells you that the main module saw the change in the submodule. Make sure you include that part in your commit in the main module.

Step 8: Push both submodule and main module to your fork, and then create pull requests for them starting with the submodule.

Now here is the nice thing: The submodule is referenced by the commit hash, which is a unique identifier. When creating a pull request, github actually creates a branch pull/123 or so in the main repo containing your commits. As the lookup by commit hash looks into all branches, the build system will find your submodule commit in the main repo. Yay!

(Disclaimer: I have not actually tested this with the sponge repos so I cannot guarantee that this works out of the box)

2 Likes