Oh wow, I didn’t even catch that nuance. I read the article and it sounded like he was being a misleading, crotchety ass about the whole situation but that golang were also refusing to engage. Having now read the git issue as well, it turns out they pretty quickly said:

In the meantime, if you would prefer, we can turn off all refresh traffic for your domain while we continue to improve this on our end. That would mean that the only traffic you would receive from us would be the result of a request directly from a user. This may impact the freshness of your domain's data which users receive from our servers, since we need to have some caching on our end to prevent too frequent fetches.

Maybe not perfect, but exactly the kind of immediate patch that’s needed when large complex systems cause problems and a full overhaul will take time.

There’s even an explicit invitation on there for him to email if needed because he’s been banned from that issue tracker.

I'm not 100% confident it is full clones. There's this comment given when Drew first asked about clones vs fetches that says:

For example, go mod download module@version (which is what proxies are expected to use to fetch a module at a particular version), isn't guaranteed to perform a single HTTP request. It may do things like first request a list of all the tags of that module, then look for the go.mod file or other metadata, then do a shallow fetch to get the contents.

From proxy.golang.org's perspective, we shell out work to the go command, and it's up to the go command to decide how best to retrieve the information and pass it back to us.

I'm far, far from being a git expert but scanning through all instances of Run(r.dir, "git", in the relevant file that would be called by go mod download, it seems to do everything it can to avoid fetching more than it has to into the local cache.

I am not 100% confident it isn't full clones, because there's a line immediately after that first quote that I'm failing to put into context:

So the idea of keeping a cache of clones around isn't practical, nor would it help the go command.

I believe it's fine because the go command itself is generating its own cache. But there's also comments like this one:

We did consider caching clones, but it has security implications and adds complexity, so we decided not to. It is certainly not trivial to do and not something we are likely to do based on this issue.

Meanwhile, on a completely different issue elsewhere, gentoo struggled with getting full clones of a 900MB repo pulled down, but that's cause they got caught in a random sample for regression testing. The fact that they didn't have excessive traffic outside of the time periods where testing was happening kinda tells me that shallow fetches are actually what's happening in the normal case.

It'd really be helpful if Drew had mentioned the actual amount of data that was being pulled off his server.