When using SourceTree's "Add Submodule" feature, the interface currently requires a full URL to the submodule repository. However, Git natively supports relative URLs (e.g., ../../lib/other_repo.git), which are especially useful when working with multiple repositories hosted on the same server (e.g., GitHub, GitLab, etc.).

This limitation forces users to hardcode full URLs, which:

• Reduces portability across forks or mirrors.
• Makes repository structures more brittle when moving between hosts or organizations.
• Contradicts Git’s built-in support for relative paths in .gitmodules.
• Additionally, when using GitLab CI/CD, GitLab Runners often fail to authenticate submodules using the same credentials or token used to clone the main project. This creates friction in CI pipelines, especially when submodules are private and hosted in the same GitLab instance.

Expected Behavior: Allow users to enter relative URLs (e.g., ../../lib/other_repo.git) when adding a submodule via the SourceTree UI.

Steps to Reproduce:

1. Open a Git repository in SourceTree.
2. Use the menu option Repository > Add Submodule.
3. Try entering a relative URL like ../../lib/other_repo.git.
4. Observe that the UI rejects it or fails to add the submodule correctly.

Suggested Fix: Update the submodule dialog to accept and correctly handle relative URLs, aligning with Git’s native capabilities.

Environment:

• SourceTree version: 3.4.23

The workaround is to add the submodule with the full URL and then go to the .gitmodules and replace it with the relative URL.