It can happen that a repository that the user pins has a stale .gitmodules file. We try hard to honour that file at the moment and try to initialise those sub-modules, however if those paths don't actually exist any longer in the repository we get an error like:
Error: Submodule definition https://github.com/ocurrent/ocurrent.git
references non-existing path ocurrent in repo
Hint: Make sure the submodule is initialized and committed in the source
repository
Git is more forgiving in this circumstance and will skip these silently. The user that is pinning likely cannot do much about that file unless they clone, modify and pin locally.
Since we do a best-effort initialisation of the submodules, I think it would also be sensible to skip ones that don't make sense instead of erorring. We can even emit a warning during solving about it if people might find that useful.
It can happen that a repository that the user pins has a stale
.gitmodulesfile. We try hard to honour that file at the moment and try to initialise those sub-modules, however if those paths don't actually exist any longer in the repository we get an error like:Git is more forgiving in this circumstance and will skip these silently. The user that is pinning likely cannot do much about that file unless they clone, modify and pin locally.
Since we do a best-effort initialisation of the submodules, I think it would also be sensible to skip ones that don't make sense instead of erorring. We can even emit a warning during solving about it if people might find that useful.