3 ms·
The problem with these sorts of "rules" is they create needless changes outside of the PR's primary focus. The PR's purpose is to do X: add a feature, fix a bug
by icedchai 5y ago
The problem with these sorts of "rules" is they create needless changes outside of the PR's primary focus. The PR's purpose is to do X: add a feature, fix a bug, whatever. Now because I've done X, you want me to do Y, a set of totally unrelated changes that ultimately are a distraction.
- ok_dad 5y agoWhy wouldn’t you submit two different branches to review? One where you fix errors for types and another for the feature with the fixes: (git main) > git checkout -b abc-1234/type-fixes <do work on types and commit it> (git abc-1234/type-fixes) > git checkout -b abc-1234/feature-branch <do work on feature and commit it> Then you can submit the feature branch as a PR on top of the type fixing branch and a PR for that branch to main. You only see the type fixing changes on that PR and only see the feature changes on its PR.
- icedchai 5y agoSeems fine to me, but in my experience these “rules” are often tied to a single PR and various automated CI checks.