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

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: <791b9a57-2855-4b2b-868d-293a86edb6c4@intel.com>
Date: Wed, 16 Jul 2025 09:47:41 +0200
From: Przemek Kitszel <przemyslaw.kitszel@...el.com>
To: Kuniyuki Iwashima <kuniyu@...gle.com>
CC: <intel-wired-lan@...ts.osuosl.org>, <netdev@...r.kernel.org>
Subject: Re: [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".
>>