None of this works if the programmer isn't the same person that writes the docs. e.g. if you have a copy-writer come along and write/update the docs before each release, then its not captured in the same commit/branch/etc.
You can have the programmer write bad documentation and file an issue for it to be improved. You can then enforce that releases don't go out until those issues have been resolved by the copywriter.
You can also implement new features in a branch with multiple authors. The branch doesn't get merged until the documentation is in good shape.
The copy editor updates the repo and while their changes won’t be in the same commit, they should be nearby.
So you still get the benefit of docs history, and being in the same place.
The biggest issue I've see is management and product who seem allergic to the actual repos for some reason.