I'd like you to help me plan (brainstorm) a rebase of the current branch onto the trunk (master) to produce a logical sequence of commits adhering to the following rules (by splitting, merging & editing commits)
- Fixes for issues that are pre-existing on the trunk should be in separate commits and should typically come first
- Refactorings or architecture improvements that enable/facilitate a feature should be separate from the feature itself, if the improvement is something we'd want to keep even without the feature (i.e. it's generally beneficial)
- If a feature can be broken down into multiple sub-features (and those sub features make sense in isolation) then those sub-features should generally be separate commits. "It doesn't make sense to ship half a car, but we can ship a car with no air conditioning or stereo".
- We do not want "fixup" commits - while we cannot change things on the base (trunk) branch (it's immutable history) the history on the feature branch is mutable. So any fixups should be combined with the thing that was introduced that needed fixing (this applies to both refactorings and new features)
- If existing code needs bulk reformatting or linting fixes, this should be a separate commit (this is really the same thing as rule #1)
- In general (excluding bulk reformatting or linting fixes as mentioned above) we should try to avoid "thrashing" on the branch (where a commit reverts changes that were made by a previous commit on the same branch).
- The code must compile and tests must pass at every commit - this is non-negotiable
- After the rebase, the git file tree must be identical to what it was before the rebase - this is non-negotiable