{"thread":{"id":"64746","subject":"Improved Rust hunk headers","startedAt":"2026-01-08T12:38:38Z","lastAt":"2026-01-08T17:29:21Z","messageCount":2,"participants":["Benno Lossin","D. Ben Knoble"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"533280","messageId":"DFJ7PJVEVOYG.377TM7121KCQJ@kernel.org","threadId":"64746","inReplyTo":null,"subject":"Improved Rust hunk headers","fromName":"Benno Lossin","fromEmail":"lossin@kernel.org","sentAt":"2026-01-08T12:38:35Z","receivedAt":"2026-01-08T12:38:38Z","isPatch":false,"sender":{"key":"lossin@kernel.org","avatar":null},"body":"Hey everyone,\n\nRecently, while looking at a Rust patch [1] for the Linux kernel, I had\nan idea to improve the hunk header for Rust code. The patch's hunk\nheader is the function defined above the addition. To me it doesn't\nprovide much value in giving context; it has been a while since I last\nlooked at that file. It would be much more useful in this case to show\nthe context `pub unsafe trait FromBytes {` instead. This is because the\nfunction that's being added is added to that trait.\n\nIn the general case it still is useful to show the function context when\nthe contents of a function are changed. Ideally, it would be possible to\nshow both the `impl` block and the function signature.\n\nI have no knowledge of the inner workings of git, so this might be a\ntall ask. But would it be possible to implement having multi-line hunk\nheaders and have a more advanced selection algorithm? AFAIK at the\nmoment a regex is used to extract the header, I think that would still\nbe sufficient for this case, if the `impl` block header is searched for\nafter the function signature.\n\nMy current solution to reviewing a patch like this is either opening the\nfile and scrolling to the change location. This isn't possible if\nearlier patches in a series already changed the file. In that case the\nonly option is to create a new worktree and apply the patch series. It\nwould be great if I didn't have to do this for simple things.\n\nCheers,\nBenno\n\n[1]: https://lore.kernel.org/all/20251216-transmute-v2-1-b23e5277ad02@google.com/\n"},{"id":"533294","messageId":"CALnO6CAGHuu9zBNRD1PV+2ej9pSq=2agP76hA3ZWXxojo7FJug@mail.gmail.com","threadId":"64746","inReplyTo":"DFJ7PJVEVOYG.377TM7121KCQJ@kernel.org","subject":"Re: Improved Rust hunk headers","fromName":"D. Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2026-01-08T17:29:09Z","receivedAt":"2026-01-08T17:29:21Z","isPatch":false,"sender":{"key":"ben.knoble@gmail.com","avatar":"https://avatars.githubusercontent.com/u/22802209?v=4"},"body":"On Thu, Jan 8, 2026 at 10:34 AM Benno Lossin <lossin@kernel.org> wrote:\n>\n> Hey everyone,\n>\n> Recently, while looking at a Rust patch [1] for the Linux kernel, I had\n> an idea to improve the hunk header for Rust code. The patch's hunk\n> header is the function defined above the addition. To me it doesn't\n> provide much value in giving context; it has been a while since I last\n> looked at that file. It would be much more useful in this case to show\n> the context `pub unsafe trait FromBytes {` instead. This is because the\n> function that's being added is added to that trait.\n>\n> In the general case it still is useful to show the function context when\n> the contents of a function are changed. Ideally, it would be possible to\n> show both the `impl` block and the function signature.\n>\n> I have no knowledge of the inner workings of git, so this might be a\n> tall ask. But would it be possible to implement having multi-line hunk\n> headers and have a more advanced selection algorithm? AFAIK at the\n> moment a regex is used to extract the header, I think that would still\n> be sufficient for this case, if the `impl` block header is searched for\n> after the function signature.\n\nI wonder if an empty hunk (that is, two adjacent headers) would break\nanything? Just thinking aloud.\n\n-- \nD. Ben Knoble\n"}]}