netdev - Re: [PATCH 00/12] ice: split ice_virtchnl.c git-blame friendly way

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2025081319-carried-liberty-dc3e@gregkh>
Date: Wed, 13 Aug 2025 07:34:54 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Przemek Kitszel <przemyslaw.kitszel@...el.com>,
	Sasha Levin <sashal@...nel.org>, intel-wired-lan@...ts.osuosl.org,
	Tony Nguyen <anthony.l.nguyen@...el.com>, netdev@...r.kernel.org,
	Kuniyuki Iwashima <kuniyu@...gle.com>, stable@...r.kernel.org
Subject: Re: [PATCH 00/12] ice: split ice_virtchnl.c git-blame friendly way

On Tue, Aug 12, 2025 at 01:57:14PM -0700, Jakub Kicinski wrote:
> 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/5b94d14e-a0e7-47bd-82fc-c85171cbf26e@intel.com/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?

We don't care, do whatever you need to for Linus's tree, and the
backports can work themselves out as needed.

thanks,

greg k-h