5 ms·
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.
by diegocg 2y ago
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.
- dilyevsky 2y agoGoogles source control system at the time (Perforce) didn’t allow for this at least easily. Not sure about now
- tantalor 2y agoAll changes need to be reviewed. That's the point of code reviews. Your suggestion would allow people to bypass the code review by just saying "oh it's just cleanup don't worry".
- YZF 2y agoMy 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.
- laurentlb 2y agoIf 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.