I know this is a joke, but it you did that I would reject the pr with the reason of too many things at once. Reopen separate PR to refactor variable names. I actually constaly get people doing this and it’s dangerous exactly for the reason you’re joking about. Makes it easier for errors to slip in.
I know you’re playing the straight man to a joke, but actually you can apply a linter, then tell GitHub to ignore the implied ownership history for the purposes of blame from that reclining pr. All such prs are massive and yet by virtue of the replayability of the linter it’s also very easy to ensure errors didn’t slip in when reviewing.
I know the original comment was about renaming all the variables, but that’s obviously deliberately absurd, so I’m using here a completely realistic example instead.
This will lead to change fatigue. People will rather not cleanup as they go anymore and just get the work done, with worse and worse code quality as a result.
This is why I always rename all the variables in the project on each PR.
I know this is a joke, but it you did that I would reject the pr with the reason of too many things at once. Reopen separate PR to refactor variable names. I actually constaly get people doing this and it’s dangerous exactly for the reason you’re joking about. Makes it easier for errors to slip in.
I know you’re playing the straight man to a joke, but actually you can apply a linter, then tell GitHub to ignore the implied ownership history for the purposes of blame from that reclining pr. All such prs are massive and yet by virtue of the replayability of the linter it’s also very easy to ensure errors didn’t slip in when reviewing.
I know the original comment was about renaming all the variables, but that’s obviously deliberately absurd, so I’m using here a completely realistic example instead.
This will lead to change fatigue. People will rather not cleanup as they go anymore and just get the work done, with worse and worse code quality as a result.