How mantainers check Git diffs and patches?

How mantainers check Git diffs and patches?

[Henrique Soares]

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

Re: How mantainers check Git diffs and patches?

[Kristoffer Haugsbakk]

On Wed, Oct 1, 2025, at 05:30, Henrique Soares wrote:
> 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.

Here is a relevant message (2016).

https://lore.kernel.org/git/20160809113703.57irthzzpg6j3dmv@sigill.intra.peff.net/

Re: How mantainers check Git diffs and patches?

[Jeff King]

On Wed, Oct 01, 2025 at 10:15:35AM +0200, Kristoffer Haugsbakk wrote:

> Here is a relevant message (2016).
> 
> https://lore.kernel.org/git/20160809113703.57irthzzpg6j3dmv@sigill.intra.peff.net/

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

Re: How mantainers check Git diffs and patches?

[Henrique Soares]

On Wed, Oct 01, 2025 at 10:15:35AM +0200, Kristoffer Haugsbakk wrote:
> Here is a relevant message (2016).
> 
> https://lore.kernel.org/git/20160809113703.57irthzzpg6j3dmv@sigill.intra.peff.net/

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

Re: How mantainers check Git diffs and patches?

[Konstantin Ryabitsev]

On Wed, Oct 01, 2025 at 12:30:43AM -0300, Henrique Soares wrote:
> 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?

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/20250919010911.649831-1-sandals@crustytoothpaste.net

This will apply it on top of the current HEAD:

    b4 shazam https://lore.kernel.org/git/20250919010911.649831-1-sandals@crustytoothpaste.net

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

    b4 shazam -H https://lore.kernel.org/git/20250919010911.649831-1-sandals@crustytoothpaste.net

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

Hope this helps,
-K

Re: How mantainers check Git diffs and patches?

[Henrique Soares]

On Wed, Oct 01, 2025 at 09:37:34AM -0400, Konstantin Ryabitsev wrote:
> This will apply it on top of the current HEAD:
> 
>     b4 shazam https://lore.kernel.org/git/20250919010911.649831-1-sandals@crustytoothpaste.net
> 
> This will fetch it into FETCH_HEAD, making it behave pretty identical to a
> pull request:
> 
>     b4 shazam -H https://lore.kernel.org/git/20250919010911.649831-1-sandals@crustytoothpaste.net

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.

> Hope this helps,

Yes, a lot! Thanks.

-- Henrique

Re: How mantainers check Git diffs and patches?

[Junio C Hamano]

Henrique Soares <henriquegogo@gmail.com> writes:

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

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.

Re: How mantainers check Git diffs and patches?

[Henrique Soares]

On Wed, Oct 01, 2025 at 09:41:46AM -0700, Junio C Hamano wrote:
> 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

Re: How mantainers check Git diffs and patches?

[Junio C Hamano]

Henrique Soares <henriquegogo@gmail.com> writes:

> On Wed, Oct 01, 2025 at 09:41:46AM -0700, Junio C Hamano wrote:
>> 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?

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.