Devising a way to deal with submodules

[iboB]

We're really missing a term here. Submodules is (rightfully) understood as git submodules in a repo. We need a word to describe a repo item which is a third party code, but is likely to be forked and modified as per the needs of this repo.

In our case this includes the submodules here (ggml and inference implementations) and also this repo itself is planned to be a submodule of the wrappers for different languages.

Handling submodules was raised in a previous private discussion before and plain git submodules were chosen, but with the public release upon us it seems that the specs should be changed. Using them has its unpleasant sides, but with a small team, where everyone has write access to everything involved, they are adequate.

Going public exacerbates the problems with git submodules, as we would expect external people to do PRs or just use and modify the SDK for their needs.

• Doing a PR which also involves a submodule needs to become two PRs (or more - one for each repo affected)
• Related changes are harder to track. If there's a lot of them, that becomes unpleasant
• Using another fork in place of a submodule becomes harder to manage

ggml and the projects which use it (such as llama.cpp and whisper.cpp) have faced similar issues and have chosen a approach which covers the first two items from the list above: splice ggml itself into the projects and manually sync and merge the upstream ggml and downstream to the projects. This is a lot of manual effort.

Can we do better?

[zah]

git subtree is one alternative, but it's not widely known:
https://www.atlassian.com/git/tutorials/git-subtree

[iboB]

This may solve the problem with the local changes, but it makes merging harder. Not sure if it would be an improvement overall (marginal at best).

It seems that this is similar to the cheap-fast-good triangle. Some solutions solve some problems, but make others worse.