[RFC] Solution how to split a file in a way that git blame looks fine

[RFC] Solution how to split a file in a way that git blame looks fine

[Przemek Kitszel]

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").

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".

Re: [RFC] Solution how to split a file in a way that git blame looks fine

[Kuniyuki Iwashima]

From: Przemek Kitszel <przemyslaw.kitszel@intel.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.


> 
> 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".
> 

Re: [RFC] Solution how to split a file in a way that git blame looks fine

[Przemek Kitszel]

On 7/16/25 00:05, Kuniyuki Iwashima wrote:
> From: Przemek Kitszel <przemyslaw.kitszel@intel.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".
>>

RE: [Intel-wired-lan] [RFC] Solution how to split a file in a way that git blame looks fine

[Loktionov, Aleksandr]

> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Przemek Kitszel
> Sent: Wednesday, July 16, 2025 9:48 AM
> To: Kuniyuki Iwashima <kuniyu@google.com>
> Cc: intel-wired-lan@lists.osuosl.org; netdev@vger.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@intel.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