Commented-out code is bad for at least two reasons:
- Things that are used by the commented-out code can change in ways that break it, and you won't notice it until you uncomment, at which point you may as well just rewrite it, depending on its size. In any case, it will incur extra effort that could've been easily spotted if the code was "live".
- People who don't know the reason for the code to be commented-out may simply delete it. It won't be a problem to be restored from source-control, but it adds extra effort to restore it later, for the same reasons as the previous point.
If you think that restoring the code (either uncommenting or restoring from source-control) won't be a problem, or in other words, if you think that nothing that is being used by this code will change and make it invalid after a while, then it would be fine to simply remove it for now, and restore it when it is needed again.
However, if you know that the code will be used in the future, and if there's any chance that something will change that may affect it, I would suggest to use an approach similar to Feature Toggles, that is, placing the code under a conditional branch that will only be executed when you "flip the switch" to on. This way your development environment will continue to remind you, and everyone else, if there are any changes that affect the "hidden" code (e.g. compiler, automated tests, etc.). Meanwhile, you have the system running in production without the feature, with the toggle off.