Remove unused Git submodules, update Linux-deps version

[mcarans]

Remove what looks like unused Mac-specific, libogg, libvorvis and tests Git submodules
Update Linux-deps version
Update Flatpak yaml to reflect FlatHub build
Remove Mac-specific document generation in Doxyfile

[AnotherCommander]

The tests repository should not be deleted. It contains, among others, the Material Test Suite OXP, which is still valid for use to this day for checking renderer functionality and is also a great example of how OXPs can be used to make something totally different and "out of the box". Additionally the tests repo contains the set of test save files for all Oolite's built-in missions which are still very important for testing. Other files contained therein are used as part of the pre-release functionality checklist described in Doc/CHECKLIST.TXT.

Please exclude the tests repo from deletion.

Mac-specific can probably be rather archived than deleted. It may still contain valuable information for anyone attempting to resurrect the Mac port at some point in the future.

[mcarans]

@AnotherCommander I haven't actually deleted (or archived) the repos themselves, just removed them from .gitmodules so they don't get checked out. I hadn't considered actually deleting the repos themselves. Does tests need to be checked out as a submodule or is it sufficient that its repo is available in OoliteProject?

Also see https://bb.oolite.space/viewtopic.php?p=304782#p304782 for a question for you on submodules.

[AnotherCommander]

If the repositories are not physically deleted then it is OK. I just saw in Files Changed tab that tests was red and the diff mentioned that "this file was deleted", that's why I thought that the PR was wiping them out. We don't really need them to be checked out so I guess it is OK to unlist them from checked out submodules. In any case, please verify that no physical deletion occurs.

Regarding the binary resources submodule you asked at the forum, I believe it was set up this way so that binary files and source code would be clearly compartmentalized, i.e. code organization related reasons. Submodules in my opinion are not a bad way to organize a github project and although they can be somewhat tricky to get one's head around them, once you start working with them you may find that they do have their uses and are not really is hard as they look. Having said that, I have no strong feelings against converting to a monorepo. I don't necessarily think it is a better way to do things either though, it is just a different way.

[mcarans]

@AnotherCommander I'm not actually sure how to verify that physical deletion won't occur. All I did in my repo with checked out deps, was delete the folders in deps and remove the entries from ".gitmodules" and ".relative_gitmodules". More submodule confusion unfortunately :( Do you have any suggestions on how to verify?

[AnotherCommander]

I don't have any suggestions either. If in doubt, do not delete the folders in deps, just remove the entries from the two gitmodule files.

[mcarans]

@AnotherCommander this from AI:

No, simply deleting the entries from .gitmodules is not sufficient. In fact, doing only that can leave your repository in a "broken" state where Git still thinks a submodule should exist but doesn't know where to find it.

To fully remove a submodule so it is never checked out again, you have to clear it from three different "layers" of the repository.

The 3-Step Removal Process

If you want to move those Oolite assets into the main repo, you should follow these steps in order:

1. Remove the "gitlink" (The Index)

As we discussed earlier, the parent repo tracks the submodule revision in the index. You must tell Git to stop tracking that path as a submodule:

git rm --cached path/to/submodule

Note: Do not put a trailing slash on the path.

2. Clean up .gitmodules and .git/config

Now you can remove the text references. Using the official command is safer than manual editing:

git config -f .gitmodules --remove-section submodule.path/to/submodule
git config -f .git/config --remove-section submodule.path/to/submodule

3. Remove the internal "Physical" Data

Git stores the actual objects for the submodule inside your parent's .git/modules folder so it doesn't have to re-download them if you change your mind.

rm -rf .git/modules/path/to/submodule

What happens if you only edit .gitmodules?

If a collaborator clones the repo after you only edited the text file:

The Index still has the gitlink: Git will see an entry in the tree that says "there is a commit here," but it won't find a corresponding entry in .gitmodules to tell it which URL to clone from.

The "Orphan" Directory: The folder might still appear in the file tree, but it will be empty or "untracked," leading to confusion during builds.

It looks like you have to delete the folder otherwise the process won't work (assuming you trust the AI's answer).

[AnotherCommander]

Looks like we both are not sure and confident how to proceed here. I certainly do not have the required experience for this (I was not the one who set up this repo originally). Generally I only trust AI answers if I am able to double- or triple- cross reference them with actual verifiable sources.

Since we are discussing a major structural repo change here, based on the above I consider the risk of borking the repo to be high. I do not wish to experiment on the Oolite repo hoping for the best. What I would suggest:

• Change this PR to only update the Linux-deps submodule so that we can get at least that one part out of the way.
• Perform experiments and/or dry runs of submodule removal in a personal repo. Once confident, then do what you will by then know works here.

[mcarans]

I'm not sure how to cleanly revert the submodule changes, so will close this and create a new PR. I'll make a local experiment as you suggest.

So far I can't say I have anything positive to say about submodules based on my limited experience with them to date. Git LFS is the modern replacement but has download limits unfortunately that would make it unsuitable. The other modern way to do it is artifacts (as happens with the MSYS2 packages for example). However, it's probably not worth the trouble to set up artifacts for what are rarely changing and not that big files.

[mcarans]

@AnotherCommander Before I open another PR, here is the experiment using test repos under my user: https://bb.oolite.space/viewtopic.php?p=304803#p304803. If you're ok with that, I'll follow those exact steps with the removal of submodules from the oolite repo and submit another PR. Please let me know.

[AnotherCommander]

Can you please check what happens if you want to checkout a previous git revision before the point of the submodule deletion? Does the repository revert back to exactly what it was before (with the submodule present as it was at the time of the revision)? Can you then checkout HEAD again and move to the latest revision with the submodule reference removed without any issues?

Apart from that point to confirm, looks good to me.