A fresh clone typically creates
[remote "origin"]
url = ...
fetch = +refs/heads/*:refs/remotes/origin/*
And indeed "+" there *is* optional. If you remove "+" from there, then your "git fetch" from origin will notice every time "origin" rewinds its branches because it fails to update your remote-tracking branches without forcing. So it is like giving "--force" to allow the origin rewind its branch tips hence your remote-tracking branches.
IOW, the statement holds for both push and fetch and the documentation is correct. But forcing vs not forcing should not affect pruning. They are totally separate concepts. So quoting the above documentation and then suddenly discussing if pruning takes place or not is a bit jarring.
Even though I do not do Windows, this is so basic a thing that I do not think there would be platform-dependent behaviour differences.
Unfortunately, the above does not reproduce for me. Here is my failed reproduction attempt.
First the set-up.
$ rm -fr /var/tmp/x && mkdir /var/tmp/x && cd /var/tmp/x
$ git init src
$ cd src
$ git commit --allow-empty -m initial
[master (root-commit) 9edb8aa] initial
$ git tag -m initial v0.0 master
$ git for-each-ref
9edb8aaed37552991a2c7578da7862ffecae1e30 commit refs/heads/master
26fb2b9f313528b70566594e621d3873e9815415 tag refs/tags/v0.0
$ cd ..
$ git clone --no-local src dst
Cloning into 'dst'...
remote: Enumerating objects: 3, done.
remote: Counting objects: 100% (3/3), done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)
Receiving objects: 100% (3/3), done.
$ cd dst
$ git tag -m ours -f w0.0 master
$ git commit --allow-empty -m second
[master 4b48c71] second
$ git tag -m 'our second' w0.1 master
$ git for-each-ref
4b48c71f0f2d3ca58eeed0d3afa71f23681dd98e commit refs/heads/master
9edb8aaed37552991a2c7578da7862ffecae1e30 commit refs/remotes/origin/HEAD
9edb8aaed37552991a2c7578da7862ffecae1e30 commit refs/remotes/origin/master
26fb2b9f313528b70566594e621d3873e9815415 tag refs/tags/v0.0
cc47a66dac78d2838e767436a44b24aaca521ef7 tag refs/tags/w0.0
9f49b658425485deff4cc1c4ea52583bfecd294a tag refs/tags/w0.1The origin (src) has a commit and a tag that points at it, the clone (dst) builds a commit on top of that, has two tags of its own.
Now the reproduction attempt comes.
$ git config set remote.origin.fetch --append '+refs/tags/*:refs/tags/*'
$ git fetch origin
$ git for-each-ref
4b48c71f0f2d3ca58eeed0d3afa71f23681dd98e commit refs/heads/master
9edb8aaed37552991a2c7578da7862ffecae1e30 commit refs/remotes/origin/HEAD
9edb8aaed37552991a2c7578da7862ffecae1e30 commit refs/remotes/origin/master
26fb2b9f313528b70566594e621d3873e9815415 tag refs/tags/v0.0
cc47a66dac78d2838e767436a44b24aaca521ef7 tag refs/tags/w0.0
9f49b658425485deff4cc1c4ea52583bfecd294a tag refs/tags/w0.1
$ git config list --local
core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true
remote.origin.url=/var/tmp/x/src
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
remote.origin.fetch=+refs/tags/*:refs/tags/*
branch.master.remote=origin
branch.master.merge=refs/heads/masterUnless this is Windows specific, which I highly doubt, there must be something that is missing from your report. Perhaps you have some configuration settings?