On Tue, 12 Aug 2025 15:28:58 +0200 Przemek Kitszel wrote: > Summary: > Split ice_virtchnl.c into two more files (+headers), in a way > that git-blame works better. > Then move virtchnl files into a new subdir. > No logic changes. > > I have developed (or discovered ;)) how to split a file in a way that > both old and new are nice in terms of git-blame > There were no much disscussion on [RFC], so I would like to propose > to go forward with this approach. > > There is more commits needed to have it nice, so it forms a git-log vs > git-blame tradeoff, but (after the brief moment that this is on the top) > we spend orders of magnitude more time looking at the blame output (and > commit messages linked from that) - so I find it much better to see > actual logic changes instead of "move xx to yy" stuff (typical for > "squashed/single-commit splits"). > > Cherry-picks/rebases work the same with this method as with simple > "squashed/single-commit" approach (literally all commits squashed into > one (to have better git-log, but shitty git-blame output). > > Rationale for the split itself is, as usual, "file is big and we want to > extend it". > > This series is available on my github (just rebased from any > earlier mentions): > https://github.com/pkitszel/linux/tree/virtchnl-split-Aug12 > (the simple git-email view flattens this series, removing two > merges from the view). > > > [RFC]: > https://lore.kernel.org/netdev/[email protected]/T/#u > > (I would really look at my fork via your preferred git interaction tool > instead of looking at the patches below).
UI tools aside I wish you didn't cut off the diffstat from the cover letter :/ It'd make it much easier to understand what you're splitting. Greg, Sasha, I suspect stable will suffer the most from any file split / movement. Do you have any recommendation on what should be allowed?
