Allow relative URL when adding a Submodule

[goran-w]

The Remote.IsValidURL() method is too restrictive, as it allows only the following types of URLs:

• https
• ssh
• Absolute path to existing (local) folder whose name ends with .git

From the docs for git submodule add :

<repository> is the URL of the new submodule’s origin repository. This may be either an absolute URL, or (if it begins with ./ or ../), the location relative to the superproject’s default remote repository

This means any path beginning with ./ or ../ should be allowed (even if not existing on local disk, since it may be relative to the default Remote repo). Using a relative path is very common when adding a submodule from the same Remote "root" (like a GitHub organization etc), or even just from a local "sibling" repo (when working without a Remote).

(BTW, a local [bare] repo directory may not always end with .git so that check could be made more elaborate...)

NOTE: Git does not allow file protocol URLs (including relative paths) by default (for vulnerability reasons), so it must be explicitly allowed. Therefore, I'd also suggest adding a new checkbox Allow file protocol URL (or similar) in the Add Submodule dialog, to insert the protocol.<name>.allow config like this when adding the submodule:
git -c protocol.file.allow=always submodule add <repo-URL> <path>

[love-linger]

Commit 9baf0cc is a bad implementation for this feature, I've reverted it.

[love-linger]

Done.

[goran-w]

Thanks, @love-linger! I noticed a few things:

• URLs of type git:// and git+<protocol>:// should probably also be validated OK?
• URLs of type http:// should probably be OK (though not recommended, for security reasons)?
• When allowing the file protocol, the Submodule URL could also be an absolute path like '/path/to/repo.git' and 'file:///path/to/repo.git' (LFS seems to have some issues with the latter on Windows, but that's beside the point).
• The implementation of ValidateRelativePath() was also changed by the above commit - it now requires the Relative Path field to start with a './' - this seems overly restrictive, since a very simple relative path like 'my_submod' (without a leading './') is allowed when calling git submodule add.
• The error message "Reletive path is required!!!" has a spelling error. HOWEVER, it should actually be allowed to leave the Relative Path field empty! See this snippet from the docs for git submodule add : If <path> is not given, the canonical part of the source repository is used ("repo" for "/path/to/repo.git" and "foo" for "host.xz:foo/.git").
• The ValidationResult string "Give path is exists already!" should instead say "Given path already exists!". (NOTE: With the -f option for git submodule add, if <path> exists and is already a valid Git repository then it is staged for commit without cloning.)

Useful links:

• https://git-scm.com/book/ms/v2/Git-on-the-Server-The-Protocols
• https://labex.io/tutorials/git-how-to-validate-git-repository-url-434201

[love-linger]

Done.

[goran-w]

Thanks, @love-linger!

Validation of Relative Path is now instead done by Git, which will give an error like this if the path is invalid:

$ git -c protocol.file.allow=always submodule add ../other_repo/ /d/Dev/test
fatal: D:/Dev/test: 'D:/Dev/test' is outside repository at 'D:/Dev/Git_repos/sandbox'

$ git -c protocol.file.allow=always submodule add ../other_repo/ ../test
fatal: ../test: '../test' is outside repository at 'D:/Dev/Git_repos/sandbox'

🛑 However, the following (absolute local path) URLs are still not validated as OK in AddSubmodule.ValidateURL(), which they should be since we're allowing file protocol when adding submodules:

• /d/Dev/Git_repos/other_repo/
• file:///d/Dev/Git_repos/other_repo/

Git accepts these URLs :

$ git -c protocol.file.allow=always submodule add /d/Dev/Git_repos/other_repo/
Cloning into 'D:/Dev/Git_repos/sandbox/other_repo'...
done.

$ git -c protocol.file.allow=always submodule add file:///d/Dev/Git_repos/other_repo/
Cloning into 'D:/Dev/Git_repos/sandbox/other_repo'...
remote: Enumerating objects: 34, done.
remote: Counting objects: 100% (34/34), done.
remote: Compressing objects: 100% (20/20), done.
remote: Total 34 (delta 5), reused 0 (delta 0), pack-reused 0 (from 0)
Receiving objects: 100% (34/34), done.
Resolving deltas: 100% (5/5), done.

SourceGit should not be more restrictive (in its validation) than Git itself...

⚠ NOTE: Actually, the same is true for AddRemote.ValidateRemoteURL() and EditRemote.ValidateRemoteURL(), since git remote add and git remote set-url are allowing absolute and relative paths, along with explicit file:// URLs, even with -c protocol.file.allow=never!

⚠ NOTE: The same goes for Clone.ValidateRemote(), since git clone allows absolute and relative paths, along with explicit file:// URLs, with the default policy of protocol.file.allow=user! (Using a relative path would work there, since it will be relative to the (required) Parent Folder field.)

[love-linger]

Please use D:/Dev/test directly instead of /d/Dev/test. The second format is not supported by System.IO.Directory.Exist method.

[goran-w]

Please use D:/Dev/test directly instead of /d/Dev/test. The second format is not supported by System.IO.Directory.Exist method.

Does SourceGit really have to check if the path exists? Git will take care of that, and is able to handle more types of paths - reasonably, any path accepted by Git should be accepted by SourceGit...

[love-linger]

Does SourceGit really have to check if the path exists? Git will take care of that, and is able to handle more types of paths - reasonably, any path accepted by Git should be accepted by SourceGit...

Of cause that we can remove all URL validations since git will take care of it.