Setting Git `ref` parameter to commit not reachable from named ref (branch/tag) fails on new fetches

[sybereal]

For the case of a new download into a nonexistent directory, the ref is passed directly to git clone --branch. However, if the specified commit is not reachable from any of the refs included in a default clone, the operation will fail, since the commit is not available without an explicit git fetch.

Interestingly, due to the branch for an existing directory invoking git fetch instead of git clone, even if said directory is empty, this issue could theoretically be worked around by creating the directory ahead of time.

go-getter/get_git.go

Lines 125 to 134 in 842d6c3

	// Clone or update the repository
	_, err := os.Stat(dst)
	if err != nil && !os.IsNotExist(err) {
	return err
	}
	if err == nil {
	err = g.update(ctx, dst, sshKeyFile, u, ref, depth)
	} else {
	err = g.clone(ctx, dst, sshKeyFile, u, ref, depth)
	}

However, when using an application that embeds go-getter, that may not always be possible.

Theoretically, the safest way would be to always use tags with go-getter. However, when dealing with work-in-progress versions during testing, tagging every commit you want to test is cumbersome and clutters the release history. This is a pitfall we have stumbled over several times when testing with a work-in-progress branch of a Terraform module:

1. Make some commits on the branch.
2. Test with them.
3. To prevent the tests automatically pulling new changes on the branch, pin the commit hash.
4. The branch gets rebased, the referenced commit is no longer reachable, even though it still exists, and go-getter fails.

If the init -> add remote -> fetch -> checkout flow was used instead of cloning, maybe only if the ref looks like a commit hash, this could be supported.