Of course it's a good idea. The commit for a change in semantics is quite distinct from the commit for a change in indentation.
However, why are you changing the indentation? The general old school rule was that the maintainer of a body of code should live with the indentation scheme of the original developer. There are exceptions upon exceptions to this rule, but the intent of the rule is to keep (1) avoid edit wars, and (2) avoid commits that have zero semantic meaning.
Suppose you do find one file in the configuration managed code base that blatantly violates your organization's coding standards. It's most likely that that is not the only file. You should create a new change request (or whatever they are called in your organization) to fix all of those problems. That one commit might hit anything from one file to thousands of them, but if the reformatting is done by a well-tested tool, it will have zero semantic impact.
The new school rule is that commits / pushes will either (a) be automatically reformatted to an agreed-upon common style upon commit /push, or (b) rejected should the code in question fail to conform with that style. Either way, you will not have a problem with code that deviates from the style with which everyone has agreed to abide.