Currently, every pull request that adds a new resource kind modifies the one and only line of config/generated.lst, which means that git finds a conflict between any two such pull requests.
This change makes such PRs no longer be conflicting, by introducing newlines.
The only potential downside I can see here is that the conflict was serving as a sign that there were some additional changes that might impact the codegen, and you should rebase and rerun make generate. But they're a poor way to indicate that. If we really want to ensure that, we can enforce a linear history, but I think simply running CI on main is probably good enough.
This will also make it much easier to maintain that linear history, since you'll be able to git merge without having to rerun codegen, and the ci check-diff job will ensure you didn't miss anything.
Thanks @turkenf. I rebased and resolved conflicts hopefully for the last time. I'll be AFK by the time the lint job finishes. Can you take care of clicking merge?
Description of your changes
Currently, every pull request that adds a new resource kind modifies the one and only line of
config/generated.lst
, which means that git finds a conflict between any two such pull requests.This change makes such PRs no longer be conflicting, by introducing newlines.
The only potential downside I can see here is that the conflict was serving as a sign that there were some additional changes that might impact the codegen, and you should rebase and rerun
make generate
. But they're a poor way to indicate that. If we really want to ensure that, we can enforce a linear history, but I think simply running CI on main is probably good enough.This will also make it much easier to maintain that linear history, since you'll be able to git merge without having to rerun codegen, and the ci
check-diff
job will ensure you didn't miss anything.I have:
make reviewable
to ensure this PR is ready for review.How has this code been tested