Reviewing patches

Featured image

Being part of the community, is more than just writing code and sending patches, it is also keeping track of the IRC discussions and reading the mailing lists to review and test patches sent from others whenever you can.

Both environments are not the most welcoming, but there are plenty of tools from the community to help parsing them. In this post I’ll talk about b4, suggested by my GSOC mentor André, a tool to help with applying patches.

Applying patches

I assume you already know that when we refer to “git commits”, we are basically talking about snapshots of the files in the repository (more about that); it’s almost like, for each set of changes, we archived and compressed the whole repository folder an gave the result a name.

Example
  • v1-created-wireframes.tar.gz
  • v2-minimum-testable-product.tar.gz
  • v2.1-fixed-download-icon.tar.gz
  • v3…

When working in a large project with so many people, like we have in the Linux Kernel community, it would be impractical to send a file containing the whole repository just to show some changes in some files, specially in the old days, when there probably wasn’t even that much bandwidth. So, in order to share your workings with the community you just have to tell them “add X to line N, remove Y from the following line”, in other words, you have to share only the differences you brought to the code.

There is a command to convert your commits into these messages showing only the “diffs” in your code: git format-patch. It’s worth mentioning that Git uses its own enhanced format of diff (see git diff), which tries to humanize and contextualize some changes, either by recognizing scopes in some languages or simply including surrounding lines in the output. So, lets say you created a couple commits based on master and want to extract them as patches, you could run git format-patch master, which would create a couple numbered files. You could then send them via email with git send-mail, but that’s another talk, my point here was just to introduce the concept of patches, you can read more at https://git-scm.com/book/en/v2/Distributed-Git-Maintaining-a-Project.

Note
Nowadays there are plenty of source-code hosts, like Github and Gitlab, that provide an alternative to email patching through Pull/Merge Request.

Now, lets say somebody has already sent their patch to some mailing list, like https://lore.kernel.org/all/20220627161132.33256-1-jose.exposito89@gmail.com/. How can you assert that their code compiles and works as described?

You could find the link and download the mbox.gz file from the lore.kernel.org page, or find the series at patchwork.kernel.org to do the same, which then would allow you to use git am to apply the patches, recreating the commits in your local environment. That process is easy enough but it can be improved as far as running a command over the lore.kernel.org URL with b4.

Info
B4 is a helper utility to work with patches made available via a public-inbox archive like lore.kernel.org. It is written to make it easier to participate in a patch-based workflows, like those used in the Linux kernel development.

B4 - it’s not an acronym, it’s just a name

B4 is a Python package and can be easily installed with python3 -m pip install --user b4. I’d suggest using a virtual environment to avoid problems with dependencies, but this post won’t cover that.

It comes with a helpful b4 --help, which tells us that, to apply the mentioned patch series you’d just need to run:

b4 am https://lore.kernel.org/all/20220627161132.33256-1-jose.exposito89@gmail.com/

Which will download the patch series as a mbox file and the cover letter as another, so that you could then use git am on it the former. With some luck (and communication), everything will apply without any conflicts.

That’s it, good luck on your reviews and thanks for reading!


“applying patch to belly” by The EnergySmart Academy is licensed under CC BY-NC-SA 2.0. To view a copy of this license, visit https://creativecommons.org/licenses/by-nc-sa/2.0/?ref=openverse.