I'm guessing the cvs2git version changed in the upgrade and the new version generates different commit hashes from the old one. You can verify this by comparing how a known commit shows up on the GitHub UI vs. a git log of a recent cvs2git conversion: if the "commit XXXXXXX" strings differ, that's our culprit.
If you don't care about preserving the hashes of the old commits on GitHub, then what you probably want is `git push --mirror origin`. It does exactly what it sounds like, mirroring the current state of the entire repo to the remote. (Doing this means that people won't be able to git pull without --rebase on checkouts of your repository made prior to the cvs2git upgrade, and if there are any antediluvian forks of it on GitHub the UI may get confused trying to figure out their relation.) If you DO care about preserving the commits with the old hashes on GitHub then I don't know how to do better than Anton's suggestion, though I think you'll still encounter problems with tags... you'd have to take the --tags off your push command and come up with some system for pushing new tags individually.
