Git shortlogs, so they can be easily identified and their purpose made clear.
The short answer is that it keeps things working while patches flow up- and downstream, and as we periodically rebase microPlatform patches on our upstream projects’ latest versions.
The details are given below in Appendix: Branch Management Rationale.
For repositories with upstreams, like Zephyr and MCUBoot, Foundries.io maintains some out of tree patches. To make this work smoothly, we typically bring in upstream changes by merging into our tree. You’ll see merge commits with
[FIO mergeup] in the shortlog when this happens. See below for a complete list of sauce tags.
However, whenever the upstream releases a new version, the Foundries.io branch history is cleaned up and re-written onto the new development tree for the next version. This is a destructive change, but you can always get the old version using the manifests from previous updates.
The notes in the microPlatform update will always make it clear when history rewrites have happened. They will also provide pointers to commits in the new update which match the last update exactly (even though history is different, the code will be the same). You can use these commits as a starting point when merging the new history into your own tree if you are also managing changes to these repositories – since the code is the same, the merge will succeed.
For source code repositories without upstreams, where Foundries.io is maintaining the code, Zephyr microPlatform updates will always contain fast-forward changes from the previous update.
This is a detailed rationale for why these rules exist.
There are two “types” of repository in a Zephyr microPlatform installation:
Rather than cloning the upstream versions of the Zephyr and mcuboot repositories in a Zephyr microPlatform installation, Foundries.io maintains its own trees. This is for two reasons.
We’re constantly upstreaming features, bug fixes, etc. We’re also constantly tracking upstream and merging updates after they pass continuous testing. We also sometimes need to keep some temporary solutions or patches in our trees which aren’t useful for upstream, but are important to our users (i.e. you!).
While this happens, Zephyr microPlatform-only repositories are also changing, both to track changes from upstream, and in their own right.
This all gets complicated, and the branching rules help keep things working smoothly: