How mantainers check Git diffs and patches?

Hello,

This is a simple question I have related to the PR diff review process.

How Git maintainers use to check diffs and review the code? I mean, sometimes I see that there are some large PATCHES that is hard or probably impossible to review only using e-mail client.

Do you use some syntax highlight in client e-mail; any pipeline that automatically download e-mails and apply to a local branch; or for each PR you save the e-mail file then "git apply" to review / test the diff?

This isn't a technical question, I'm just curious about how you do it.

-- Henrique

Here is a relevant message (2016).

https://lore.kernel.org/git/[email protected]/

Oh good, you just saved me a lot of digging and/or retyping. ;) I think that message is a bit more philosophical, but in the thread below it there are some actual scripts and mutt commands I use. I'm sure they've probably gotten some small bug fixes over the years (especially the patch-sending script), so if anybody is reading them as more than just inspiration, let me know and I am happy to share a more current version.

-Peff

Hey, this thread is pure gold.

There are a lot of comparisons with GitHub PRs (BTW, that wasn't my motivation), but besides this, it's pretty nice to see the review process in "e-mail flow".

E-mail threads are really great for discussions but before I follow Git mailing list I did never realize how useful they are to PR reviews as well.

-- Henrique

There are tools that make it easy to apply a patch series to your local tree. For example, here's a random patch series from the list:

    https://lore.kernel.org/git/[email protected]

This will apply it on top of the current HEAD:

    b4 shazam https://lore.kernel.org/git/[email protected]

This will fetch it into FETCH_HEAD, making it behave pretty identical to a pull request:

    b4 shazam -H https://lore.kernel.org/git/[email protected]

From here, you can check out FETCH_HEAD to run tests or do a commit-by-commit review.

Hope this helps,
-K

I just didn't know about b4, and this is probably the tool I was looking for. Basically what I was doing was git apply patch-by-patch manually (with a little scripting), but b4 seems the right tool for the job.

Yes, a lot! Thanks.

-- Henrique

Even a very small patch that applies a change to an early part of an ultra-long function may be hard to assess depending on how far the effect of that change gets propagated through the code flow to affect the code near the bottom of the function.

Patches are medium for reliable transmission. Once you apply the patch to your tree (perhaps giving it its own topic branch, perhaps to a detached HEAD with the full intention that you will discard it after you are done inspecting the change the patch brings in), you can use any regular tools you use while developing and reviewing your own code.

It makes totally sense. So I suppose you avoid to review the code just checking the e-mail patch in e-mail client, but first applying locally and then check it in your code editor in a separate branch, worktree or whatever, then back to e-mail thread and comment the code, right?

-- Henrique

The other way around. With experience with the codebase, you'd learn to tell if a small-looking patch is truly small and only need the patch text to judge, would be helped if I have another window and have the code that would be modified if I were to apply the patch without actually applying, or its ramification is deep enough that I better apply it before making the final decision. For a truly complex patch series I'd first apply them and then read with "git log --reverse -p" with wider context (e.g., -W or -U8), occasionally looking at the entire file at the step in question with something like "git show HEAD~4:path/to/that/file". It does not happen all that often, but it is not so rare.