If you do it that way, then what should be a 1-line BUILD file change turns into something that changes every line. It distracts from the actual purpose of the future change. Many directories aren't touched for long periods of time. A few months from now someone tries to make a 1-line change and is unpleasantly surprised they have to deal with tons of seemingly spurious formatting changes. Not good.
Putting the time of submitting the changes on a small team (mostly me, with approvals from Rob and help from Laurent) was absolutely the right tradeoff. It avoided the "unfunded mandate" and tech debt of making everyone else deal with it.
Update: I found the FAQ we wrote back then. It was very short. These were the last two questions:
Q: Who will update all the existing BUILD files?
A: We will. There are nearly 200,000 of them, and we’ll take care of that. We’re sending CLs out now. If you want to do it yourself, that’s fine: see go/buildifiernow for a tool that can help.
Q: You’re creating a lot more work for me.
A: We are creating significant amounts of work for ourselves, including reformatting all 193,000 BUILD files in google3. For the rest of the engineers in the company, we intend to make the transition as smooth as possible, with integration in Eclipse, Emacs, and Vim, as well as tools like Rosie and GenJsDeps. It is an explicit goal not to create significant work for other engineers. If, as we roll this out, you find that we’ve created noticeable work in your workflow, please let us know so that we can address that.
Make the one line change be a commit, then the reformatting be another one, review only the first one. It shouldn't be a problem with a proper review system.
If every engineer needs to make two commits when they change the build file, that's a higher cost compared to having people dedicated to the migration.
My understanding is the 100k changes files were not reviewed by a human, they did some automatic validation, so that validation could also be done on demand, e.g. a commit saying "reformatted" could trigger a check to make sure the files were identical and bypass a human review... but sounds like they chose a reasonable approach.
I've always been against "reformat the whole code base" but it's an interesting example where it seems to have been the right choice.
Putting the time of submitting the changes on a small team (mostly me, with approvals from Rob and help from Laurent) was absolutely the right tradeoff. It avoided the "unfunded mandate" and tech debt of making everyone else deal with it.
Update: I found the FAQ we wrote back then. It was very short. These were the last two questions:
Q: Who will update all the existing BUILD files?
A: We will. There are nearly 200,000 of them, and we’ll take care of that. We’re sending CLs out now. If you want to do it yourself, that’s fine: see go/buildifiernow for a tool that can help.
Q: You’re creating a lot more work for me.
A: We are creating significant amounts of work for ourselves, including reformatting all 193,000 BUILD files in google3. For the rest of the engineers in the company, we intend to make the transition as smooth as possible, with integration in Eclipse, Emacs, and Vim, as well as tools like Rosie and GenJsDeps. It is an explicit goal not to create significant work for other engineers. If, as we roll this out, you find that we’ve created noticeable work in your workflow, please let us know so that we can address that.