Internally, go-getter should transform the provided string into a file:// URI with an absolute filepath, with query string params and subdirectory notation retained.
The rationale for using a file:// URI internally is that the Git clone operation can work with file:// URIs, and using them for this feature would allow us to leverage the existing go-getter URI-handling machinery. That would get us support for query params (to clone a specific git ref (tag, commit hash, ...)) "for free".
The rationale for using an absolute filepath (even when the provided string is a relative filepath) is that (per RFC 1738 and RFC 8089) only absolute filepaths are legitimate in file:// URIs. But more importantly, the Git clone operation only supports file:// URIs with absolute paths.
Q: Why support this functionality at all?
Why not just require that a source location use an absolute path in a file:// URI explicitly if that's what is needed?
A: The primary reason is to allow support for relative filepaths to Git repos.
There are use cases in which the absolute path cannot be known in advance, but a relative path to a Git repo is known.
For example, when a Terraform project (or any Git-based project) uses Git submodules, it will know the relative location of the Git submodule repos, but cannot know the absolute path in advance because it will vary based on where the "superproject" repo is cloned. Nevertheless, those relative paths should be usable as clonable Git repos, and this mechanism would allow for that.
Support for filepaths that are already absolute would be provided mainly for symmetry. It would be surprising for the feature to work with relative file paths, but not for absolute filepaths.
For projects using Terraform, in particular, this feature would enable the non-fragile use of relative paths in a module "call" block, when combined with Git submodules:
In the above example "superproject" Git repo (the one "calling" the terraform module) knows the relative path to its own Git submodules because they are embedded in a subdirectory beneath the top-level of the "superproject" repo.
There are at least two downstream Terraform issues open that would require go-getter support for this feature:
hashicorp/terraform#25488: "Unable to use relative path to local Git module"
hashicorp/terraform#21107: "In 0.12, modules can no longer be installed from local git repositories at relative paths"
I have a branch that implements this feature. I'll open a PR to get feedback on it shortly.
It would be cool if the
git::
forcing token could be used on local file system paths, both absolute paths and relative paths. For example:or:
Internally,
go-getter
should transform the provided string into afile://
URI with an absolute filepath, with query string params and subdirectory notation retained.The rationale for using a
file://
URI internally is that the Git clone operation can work withfile://
URIs, and using them for this feature would allow us to leverage the existinggo-getter
URI-handling machinery. That would get us support for query params (to clone a specific git ref (tag, commit hash, ...)) "for free".The rationale for using an absolute filepath (even when the provided string is a relative filepath) is that (per RFC 1738 and RFC 8089) only absolute filepaths are legitimate in
file://
URIs. But more importantly, the Git clone operation only supportsfile://
URIs with absolute paths.Q: Why support this functionality at all?
Why not just require that a source location use an absolute path in a
file://
URI explicitly if that's what is needed?A: The primary reason is to allow support for relative filepaths to Git repos.
There are use cases in which the absolute path cannot be known in advance, but a relative path to a Git repo is known.
For example, when a Terraform project (or any Git-based project) uses Git submodules, it will know the relative location of the Git submodule repos, but cannot know the absolute path in advance because it will vary based on where the "superproject" repo is cloned. Nevertheless, those relative paths should be usable as clonable Git repos, and this mechanism would allow for that.
Support for filepaths that are already absolute would be provided mainly for symmetry. It would be surprising for the feature to work with relative file paths, but not for absolute filepaths.
For projects using Terraform, in particular, this feature would enable the non-fragile use of relative paths in a
module
"call" block, when combined with Git submodules:In the above example "superproject" Git repo (the one "calling" the terraform module) knows the relative path to its own Git submodules because they are embedded in a subdirectory beneath the top-level of the "superproject" repo.
There are at least two downstream Terraform issues open that would require
go-getter
support for this feature:I have a branch that implements this feature. I'll open a PR to get feedback on it shortly.