Message-ID: <IA3PR11MB8986FCCB195AF1EB805743C5E556A@IA3PR11MB8986.namprd11.prod.outlook.com>
Date: Wed, 16 Jul 2025 15:49:43 +0000
From: "Loktionov, Aleksandr" <aleksandr.loktionov@...el.com>
To: "Kitszel, Przemyslaw" <przemyslaw.kitszel@...el.com>, Kuniyuki Iwashima
	<kuniyu@...gle.com>
CC: "intel-wired-lan@...ts.osuosl.org" <intel-wired-lan@...ts.osuosl.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: [Intel-wired-lan] [RFC] Solution how to split a file in a way
 that git blame looks fine



> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@...osl.org> On Behalf
> Of Przemek Kitszel
> Sent: Wednesday, July 16, 2025 9:48 AM
> To: Kuniyuki Iwashima <kuniyu@...gle.com>
> Cc: intel-wired-lan@...ts.osuosl.org; netdev@...r.kernel.org
> Subject: Re: [Intel-wired-lan] [RFC] Solution how to split a file in
> a way that git blame looks fine
> 
> On 7/16/25 00:05, Kuniyuki Iwashima wrote:
> > From: Przemek Kitszel <przemyslaw.kitszel@...el.com>
> > Date: Tue, 15 Jul 2025 22:33:40 +0200
> >> Hi,
> >>
> >> 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
> >>
> >> https://github.com/pkitszel/linux/commits/virtchnl-split/
> >>
> >> The purpose of RFC is to ask if anyone is in strong disagreement
> with
> >> me
> >>
> >> 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").
> >
> > FWIW, git-blame has -M/C to track X-times line moves within/across
> files.
> 
> those switches are great, agree (with a tad inconvenience that you
> likely want to specify -C10 to have it work harder)
> 
> but even then, I find my "elaborate" method superior, as it allows
> for easy "go to previous revision on given line" operation, while
> with simple squashed/single-commit variant there is simply no
> previous commit on the (new) file
> 
> For example in tig (which is the state-of-the-art tool in terms of
> interactive git archeology) you can simply go back on given line
> with a single keystroke (likely to go prior the "static" kw removal,
> to see signature changes made prior to moving stuff into new file),
> but with squashed variant there is simply no place to go, what
> result in the msg:
> "The selected commit has no parents with this file"
> 
> This is possibly resolved by specifying "-C -C" for git-blame, but
> it is simply so slow on kernel repo that I didn't checked how it
> looks.
> 
> >
> >
> >>
> >> 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".
> >>

For my educated opinion
This is a well-justified and technically sound refactor. While it may
seem like overkill at first glance, the long-term benefits — especially
in a project like the Linux kernel — are substantial.

1. Improves long-term maintainability
  Kernel code lives for decades. Preserving history is not just a nicety
  — it’s a necessity.
  Future contributors will benefit from being able to trace changes
  accurately.
2. Avoids reliance on -M -C
  While git blame -M -C can track moved/copied lines, it:
  Is not always enabled in tools (e.g., GitHub, GitLab, IDEs).
   Can be slow on large repos like the Linux kernel.
   Doesn’t always work well with partial refactors or interleaved logic changes.
3. Minimal cost
  The downside is a slightly noisier git log, but:
  This is a one-time cost.
  The benefit to git blame is permanent and ongoing.

Alex

Powered by blists - more mailing lists