The documented URL format is codecommit://profile@repository, where "profile" is effectively placed as the username and "repository" as the hostname when following typical URL rules.
The parsing code uses urlparse and then inspects the various parts, but it totally ignores the path portion of the URL.
The tool will therefore accept a URL like codecommit://profile@repository/any/other/nonsense, but will silently discard the path and just treat it the same as codecommit://profile@repository, therefore still cloning the entire repository.
Since the path portion has no meaning, I'd suggest making it an error to specify a non-empty path, explicitly stating that a path is not allowed. Because Git repositories conceptually contain a filesystem subtree, it's tempting for someone to think that a path portion will clone a subdirectory of the repository, even though that's not technically possible due to how Git works. Returning an error would therefore give better feedback to someone who has made that mistake.
The documented URL format is
codecommit://profile@repository, where "profile" is effectively placed as the username and "repository" as the hostname when following typical URL rules.The parsing code uses
urlparseand then inspects the various parts, but it totally ignores the path portion of the URL.The tool will therefore accept a URL like
codecommit://profile@repository/any/other/nonsense, but will silently discard the path and just treat it the same ascodecommit://profile@repository, therefore still cloning the entire repository.Since the path portion has no meaning, I'd suggest making it an error to specify a non-empty path, explicitly stating that a path is not allowed. Because Git repositories conceptually contain a filesystem subtree, it's tempting for someone to think that a path portion will clone a subdirectory of the repository, even though that's not technically possible due to how Git works. Returning an error would therefore give better feedback to someone who has made that mistake.