Please follow CONTRIBUTING.md and manual#submitting-changes-making-patches and squash the fix-up commits.

This can be done without git rebase -i by doing:

git reset HEAD~1                    # move fix-up commits into unstaged
git add -- pkgs/                    # move changes into staged
git commit --amend --no-edit        # add changes to previous commit
git push ... ... --force            # modify current PR branch

However, git rebase -i is a more powerful alternative, I created a small video demonstrating it's use here. A more indepth text tutorial can be found here

WFM non-nixos linux x86_64

Please follow CONTRIBUTING.md and manual#submitting-changes-making-patches and squash the fix-up commits.

Done.

But in no way I can read from CONTRIBUTING that fixup commits should be squashed. And I would assume nobody picks that up from the sentence "If you have commits pkg-name: oh, forgot to insert whitespace: squash commits in this case. Use git rebase -i." in the manual either (it's quite hidden).

Also, you started making code suggestions, where you have to expect people pushing the "commmit" button resulting in a commit to the PR... 🤷‍♂️ And I don't really understand what's the point, since one can simply squash when merging here on GitHub, avoiding re-evaluation of ofborg?!

Also, you started making code suggestions, where you have to expect people pushing the "commmit" button resulting in a commit to the PR... man_shrugging

I usually make the edits locally, re-build the package. Doing those changes locally are easier

And I don't really understand what's the point, since one can simply squash when merging here on GitHub, avoiding re-evaluation of ofborg?!

It's not for your benefit, it's for the benefit of those reviewing your PR. I'm sacrificing my free time to review the changes. In general, it's not very rewarding to do reviews.
I get 20-120 github notifications in a day. Having to spend additional time "cleaning up" after others contributes burn out.

Not to mention that your PR just "happens" to be only one commit, so squashing happens to be a possibility in this one instance.

The nixpkgs manual uses the term "logical units"; the term is vague, but it allows for the flexibility needed when doing non-conventional changes. In any case, I don't think a comment and some formatting warrants a separate commit.

this was marked broken in #99956 , please rebase, and unmark it as broken

It's not for your benefit, it's for the benefit of those reviewing your PR. I'm sacrificing my free time to review the changes. In general, it's not very rewarding to do reviews.
I get 20-120 github notifications in a day. Having to spend additional time "cleaning up" after others contributes burn out.

But is it really less work to explain the squashing machinery each time and having to revisit the PR at a later time than to simply choose the right button (especially - as in this case - if the changes are from yourself basically?) You don't have to answer, I don't want to start a discussion here... just a thought.

this was marked broken in #99956 , please rebase, and unmark it as broken

Done. Thanks ❤️ !

But is it really less work to explain the squashing machinery each time and having to revisit the PR at a later time than to simply choose the right button (especially - as in this case - if the changes are from yourself basically?

It is less work the first time. But it's more to set expectations, so that further contributions are easier to review.

Also avoids having to do, "it was okay in this one previous PR because it was only meant to be a single commit, so i could squash it. But in this one you have 2 package additions and a version bump, so that's not something I can easily do from github."