Yes, that would be the way to do it. And that is <i>exactly</i> why a change like that is <i>just</i> as dangerous as any other.<p>I did quite a bit of code review during a contract earlier this year. One day one of the programmers shows up with a 100K line changeset, a reformatting and clean up that he&#x27;d embarked on of his own accord. Imagine his surprise when I point blank refused the commit. He was extremely upset (understandably, it was a lot of work and well intended) but at the back of my mind were two things: one, we are already under pressure to get things to work and this does not add anything functional. two, if it <i>does</i> add anything functional it will be an error or a bug and there is no way I&#x27;m going to catch this manually reviewing all these changes (across 100&#x27;s of files). So the safe thing to do is to simply not accept the change unless I can free up developer time to break this massive commit into smaller ones that can be reviewed and accepted one-by-one over a longer period of time. And that was a luxury we could not afford.<p>So too bad, one <i>very</i> inflexible reviewer and one <i>very</i> pissed off programmer. 1000 trivial changes in a single commit isn&#x27;t going to fly (at least, not with me), unless I review each and every one of those with just as much attention as I would review a much smaller commit. It&#x27;s that sort of attention to process details that probably makes me &#x27;less than easy&#x27; (to put it mildly) to work with but I really feel that if a customer trusts me that I&#x27;m going to have to earn that and rubberstamping a change set because it is too large to review is definitely a breach of that trust.