Hacker News new | ask | show | jobs
by icedchai 1524 days 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.
1 comments
ok_dad 1524 days ago
Why 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.
link
icedchai 1524 days ago
Seems fine to me, but in my experience these “rules” are often tied to a single PR and various automated CI checks.
link