What are you trying to do? Are you embarrassed that you arrived at an end goal via a suboptimal sequence of steps, and are trying to present it in a way that conceals that fact? Is the auditor at the door? What's the end goal here?
What are you trying to do? Are you embarrassed that you arrived at an end goal via a suboptimal sequence of steps, and are trying to present it in a way that conceals that fact? Is the auditor at the door? What's the end goal here?
Both of these features aren't very useful when they point at a "wip" or similar commit message.
By all means push lots of little commits to your branch while you're figuring stuff out, but squash and rewrite history into logical commits (usually just one) before landing the change on main.
The solution was to identify our changes, split them into meaningful feature commits, keeping upstream and our code as separate as possible. After this change, updating the upstream by ~2 years took about 4 days. Most importantly, the history is kept clean by marking what commits go where, and doing cleanup every couple of months (no code diffs are allowed at that moment, only git history may be rewritten).
The new history can also be exported as patches, so that any client can (selectively) apply them on top of their own hostapd.