Well, they included some MPL 2.0 repos of mine at least, but skipped others that use GPL3. Yet another that is a mirror of some otherwise lost firmware files for early 2000s wifi cards (and definitely isn’t free software) is also included.
So possibly they filter out GPL2/3 specifically, rather than only include known permissive licenses. Which is a pretty bad way of doing it.
For me this is a killer feature. For a start, we value atomic commits, where each commit does one small standalone thing. This makes review easier, as well as going back and looking at history to figure out why something was done the way it was. An easy to read history is critical at a large company. Commit messages are often muliline and long and describe the why and why not other alternatives that were considered.
But this also means your PR branch should have clean history, and editing said history is absolutely encouraged (even mandatory). We use azure devops and flawed as it is, the review UI handles this case well. I believe github is far worse at handling force pushes.
Review, design review and even CI runs takes time, so I often need to start building on top of a PR before it is fully finished and merged. Because I work in a sector where we have actual certifications (safety critical systems, think things like brake controllers, medical devices, etc) this means “move fast and break things” just isn’t an option (nor should it be). This also slows down the PR workflow. Even after the C++ code built, you can expect a few hours to run the test suite with full physical simulations. And review can take days for larger and more critical changes.
So yes, many branches have more than one commit. And it is not uncommon to build upon yet to be merged branches (with the knowledge that small things will need to change as the followup is being rebased on top of changes of the original PR).
Actually, unlike on Windows, fwupd itself contains the code to flash firmware on various types of devices, and all the manufacturer provides is the firmware file itself.
On Windows you can (apparently) provide an arbitrary installer yourself instead. That said, theoretically a UEFI upgrade could mess with your system since that firmware ends up running on the main CPU itself.
It is also conceivable that you could have rogue firmware on some other device that can mess with the system via DMA (direct memory access). But then we are talking full on hacking, and likely unreliable across different kernel versions etc. Notably monitors don’t have such access. Enabling the IOMMU should also help protect against this (since that restricts what RAM addresses each peripheral can access).