Yeah, making head reduction into its own separate patch would make things
clearer, I guess.
But if you are going to do that, then the order should be 2/1/3 from the
above list. In a series of patches, restructuring without changing
semantics should come first to make existing logic cleaner and later
enhancements on top of it easier to follow. Then you build new features
and enhancements on top of that solidified base.
Because "head reduction" changes the semantics (making it better or worse
does not matter --- "changes" is what matters), it should come after #2
above, I think.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html