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 On Behalf > Of Przemek Kitszel > Sent: Wednesday, July 16, 2025 9:48 AM > To: Kuniyuki Iwashima > Cc: [email protected]; [email protected] > 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 > > 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
Re: [Intel-wired-lan] [RFC] Solution how to split a file in a way that git blame looks fine
From: Przemek Kitszel 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: [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 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".
[Intel-wired-lan] [RFC] Solution how to split a file in a way that git blame looks fine
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".
