Thanks for the clear steps to reproduce the problem.

The root cause seems to be that your HTTPS server is not serving a <meta name="go-import" […]> tag for the path git.sr.ht/~graywolf/foo/bar — it is only serving a tag for the /foo prefix:

example.com$ curl -sL https://git.sr.ht/~graywolf/foo | grep -A1 go-import
<meta name="go-import"
  content="git.sr.ht/~graywolf/foo git https://git.sr.ht/~graywolf/foo">

example.com$ curl -sL https://git.sr.ht/~graywolf/foo/bar | grep -A1 go-import

example.com$

That causes the go command to believe that there is no such module for that path.
Probably the best we could do in the go command is emit a better diagnostic for this case, but it's not obvious to me how we could detect it in general.

Or, perhaps we can improve the documentation for the remote import path protocol.

What documentation were you using when setting up the server?

CC @jayconrod @thepudds

But github does not provide that either

+$ curl -sSf https://github.com/graywolf/foo | grep -A1 go-import
  <meta name="go-import" content="github.com/graywolf/foo git https://github.com/graywolf/foo.git">

+$ curl -sSf https://github.com/graywolf/foo/bar | grep -A1 go-import
curl: (22) The requested URL returned error: 404 Not Found

and over there it works just fine. As far as I can tell only difference is the .git in the repository path on github

+$ curl -sSf https://github.com/graywolf/foo | grep -A1 go-import
  <meta name="go-import" content="github.com/graywolf/foo git https://github.com/graywolf/foo.git">

+$ curl -sSf https://git.sr.ht/~graywolf/foo | grep -A1 go-import
<meta name="go-import"
  content="git.sr.ht/~graywolf/foo git https://git.sr.ht/~graywolf/foo">

Actually, when I try to import it as foo.git in "kinda" works even from the source hut

+$ cat sr2.go
package main

import (
        "fmt"
        "git.sr.ht/~graywolf/foo.git/bar"
)

func main() {
        fmt.Println(bar.Bar())
}
+$ go run sr2.go
go: finding git.sr.ht/~graywolf/foo.git latest
go: finding git.sr.ht/~graywolf/foo.git/bar latest
go: git.sr.ht/~graywolf/foo.git/bar: git.sr.ht/~graywolf/foo.git/bar@v0.0.0-20191019153505-33a4721605aa: parsing go.mod:
        module declares its path as: git.sr.ht/~graywolf/foo/bar
                but was required as: git.sr.ht/~graywolf/foo.git/bar

What documentation were you using when setting up the server?

I do not know, it's a hosted service not setup by me.

/cc @ddevault

See this issue:

#32260

The fix has landed for the next Go release.

Err, no, that was cgo-specific. This may be a git.sr.ht bug.

But github does not provide that either

GitHub is (unfortunately) a hard-coded special case at the moment, so that's probably why it works there. (But that means that GitHub is not a good example to follow when constructing your own go-import tags.)

See also #26134.

It's really shame that biggest open source hosting is special cased so it cannot be used for comparing with other implementations. Are there any plans to de-hard-code them?

It's also a shame that Golang has to be special cased for every repository hosting platform. I'd really rather have a more general solution than adding Go-specific meta tags to each repo.

@ddevault, per https://golang.org/cmd/go/#hdr-Remote_import_paths, you can always use a .git path suffix in lieu of the go-import tag. (The go-import tag is only needed to tell the go command where the repo root is within the path and which VCS to use, and the suffix communicates both of those.)

@graywolf we have no plan to remove the hard-coded paths at this time. Presumably as a first step we would have to get upstream fixes for them to implement the full go-import protocol. 😅

Not about the error message or go get mechanisms, but sr.ht fixed its implementation of remote import protocol on Dec 19.
https://git.sr.ht/~sircmpwn/git.sr.ht/commit/2bdb70d928f1e41e1d4fa1e15e24246f0c37873a

"Fixed". I still think it's really silly that a git repo has to have language-specific meta tags. There really ought to be a more universal standard.

@ddevault complains he got blocked on this repo. Is it some kind of ban done by a bot?

It's quite strange to me that Go has given specific exceptions to the go-import meta tag requirement for popular package repositories. I found this issue when I discovered that GitHub still implements go-import wrong for subdirectories.

At the very least this behavior should be documented - at the moment the docs seem to say that GitHub's go-import tags are actually used by go get:

GitHub and other popular hosting services respond to ?go-get=1 queries for all repositories, so usually no server configuration is necessary for modules hosted at those sites.