rn-133: tiny fixes (2/3) covering the article and spotlight.

Author: mjaix

rev_news/drafts/edition-133.md

@@ -42,13 +42,13 @@ This edition covers what happened during the months of February and March 2026.
 
   The incident had originated in the i3 window manager project, where a
   commit message contained an unindented diff for illustration purposes.
-  When Debian packagers later applied the patch using patch(1), the diff
+  When Debian packagers later applied the patch using `patch`, the diff
   in the commit message was applied as actual code, sneaking a spurious
-  `sleep(1)` call into the Debian unstable package. Matthias asked the
+  `sleep` call into the Debian unstable package. Matthias asked the
   list whether this was a known issue and whether it could be an attack
   vector.
 
-  To understand why this happens, it helps to know how git-am(1) parses
+  To understand why this happens, it helps to know how `git am` parses
   its input. When processing a patch email, it must split the stream into
   two parts: the commit message and the actual patch to apply. It does
   this by treating the first occurrence of any of the following lines as
@@ -59,23 +59,23 @@ This edition covers what happened during the months of February and March 2026.
   - a line beginning with `Index: `.
 
   Everything before that boundary becomes the commit message; everything
-  after is fed to the patch application machinery. Crucially, git-am(1)
+  after is fed to the patch application machinery. Crucially, `git am`
   scans from the top of the email, so the very first such line it
   encounters terminates the commit message regardless of whether that
   line was meant to be part of the message text.
 
   This design dates back to the tool's origins. As Jeff King (also known
-  as "Peff") quickly explained in reply to Matthias, git-am(1) was
+  as "Peff") quickly explained in reply to Matthias, `git am` was
   originally designed to handle patches sent by all kinds of people, not
   just Git users. A contributor might have generated a diff with plain
   GNU `diff` and typed the rest of the email by hand, without any `---`
   separator. The tool was therefore intentionally permissive: it would
   find a `diff -` line anywhere in the email and treat it as the start
   of the patch. Peff demonstrated this with a live example. He fed
-  git-am(1) a hand-typed email containing a GNU diff, and it produced the
+  `git am` a hand-typed email containing a GNU diff, and it produced the
   expected commit.
 
-  This historical context also explained why git-am(1) is notoriously
+  This historical context also explained why `git am` is notoriously
   hard to fix: "I don't think there is a way to unambiguously parse the
   single-stream output that format-patch produces," Peff wrote, noting
   that he could find at least three earlier discussions of the same
@@ -93,54 +93,54 @@ This edition covers what happened during the months of February and March 2026.
   someone should be reading the commit message before applying. But
   Matthias pushed back: the whole point was that nobody realized the
   behavior was there. He called it "sheer luck" that it was only a
-  `sleep(1)` and not something more malicious crafted as a diff in the
+  `sleep` and not something more malicious crafted as a diff in the
   commit message.
 
-  Florian Weimer wondered whether the git-format-patch(1) output was
+  Florian Weimer wondered whether the `git format-patch` output was
   really ambiguous, given that the patch section is normally preceded by
   a diffstat block. Peff replied that the diffstat is optional and is not
   even parsed by the receiving side at all.
 
-  Jakob Haufe added an important nuance: even if git-am(1) was fixed to
+  Jakob Haufe added an important nuance: even if `git am` was fixed to
   require indented diffs, it would only partially mitigate the problem,
-  because patch(1) (which many distributions use to apply upstream
+  because `patch` (which many distributions use to apply upstream
   fixes to packages) is even more permissive. It will strip a consistent
   level of indentation from diffs before applying them. He quoted the
   patch(1) manual page: "If the entire diff is indented by a
   consistent amount, [...] this is taken into account." The i3 incident
-  had in fact been triggered by patch(1), not git-am(1).
+  had in fact been triggered by `patch`, not `git am`.
 
   Kristoffer Haugsbakk synthesized this into a clear summary of the
   situation and immediately proposed documenting it.
 
   Matthias also highlighted the broader applicability beyond email
   workflows: Linux distributions like NixOS routinely fetch patches
   directly from upstream Git repositories and apply them to packages
-  using patch(1). He noted that even after 15 years of using Git and
+  using `patch`. He noted that even after 15 years of using Git and
   being comfortable with email patch workflows, he himself had not known
   about this behavior.
 
   Several directions were then explored to look for solutions.
 
-  Peff observed the irony that git-format-patch(1) does have a `--attach`
+  Peff observed the irony that `git format-patch` does have an `--attach`
   option which puts the message and the patch in separate MIME parts —
-  making them unambiguous in principle. However, git-mailinfo(1) (which
-  powers git-am(1) under the hood) decodes both parts into a single
+  making them unambiguous in principle. However, `git mailinfo` (which
+  powers `git am` under the hood) decodes both parts into a single
   stream and still treats a `diff` line in the message part as the start
   of a patch. Fixing this would require careful surgery to avoid
   breaking the existing forgiving handling of patches received as a
   single attachment.
 
   Patrick Steinhardt suggested that even if parsing cannot be made
-  unambiguous, git-am(1) could at least detect the ambiguity and bail by
+  unambiguous, `git am` could at least detect the ambiguity and bail by
   default with an `--accept-ambiguous-patch` override. Jacob Keller
   proposed going further: a new "unambiguous mode" where
-  git-format-patch(1) would produce output that new versions of git-am(1)
+  `git format-patch` would produce output that new versions of `git am`
   could distinguish unambiguously, while old versions would still handle
   the common case the same way as before.
 
   Jacob had also sketched a concrete scheme: add a new unambiguous
-  marker after the `---` separator, so that old versions of git-am(1)
+  marker after the `---` separator, so that old versions of `git am`
   would still cut at the `---` and ignore everything up to the diff, while
   new versions would wait for the new marker and correctly ignore any
   diff appearing before it. Since the new marker would come after `---`,
@@ -152,7 +152,7 @@ This edition covers what happened during the months of February and March 2026.
   multiple markers. He explored further options: reversible quoting of
   `---` and `diff` lines in the commit message (analogous to the `>From`
   quoting used in mbox files), applied only when the message would
-  otherwise be ambiguous. This way, if an older git-am(1) received the
+  otherwise be ambiguous. This way, if an older `git am` received the
   mail, the worst case would be visible quoting in the commit message —
   ugly but readable. Junio Hamano, the Git maintainer, added another
   thought: refusing to accept unsigned patches at all.
@@ -216,7 +216,7 @@ This edition covers what happened during the months of February and March 2026.
      message for unindented `diff -` and `Index: ` lines and reject the
      commit with a helpful error message.
   3. Added a further check to detect `---` separator lines in the message
-     body, which would cause git-am(1) to silently truncate the commit
+     body, which would cause `git am` to silently truncate the commit
      message.
 
   Peff reacted with measured skepticism to patch 3 in
@@ -234,7 +234,7 @@ This edition covers what happened during the months of February and March 2026.
 
   Peff confirmed he used the same trick. Phillip, acknowledging that at
   least three developers relied on this behavior, decided to drop patch 3
-  entirely, reducing the series from three patches to two, in
+  entirely, reducing the series from three patches to two in
   [version 2](https://lore.kernel.org/git/cover.1770993281.git.phillip.wood@dunelm.org.uk).
   He also refined the diff detection in the body: the v2 correctly skips
   the first paragraph of the message (which becomes the email Subject
@@ -248,7 +248,7 @@ This edition covers what happened during the months of February and March 2026.
   --cleanup=scissors --verbose` and was satisfied.
 
   The discussion did not lead to a fundamental fix to the ambiguous
-  parsing in git-am(1), which remains an open problem with no obvious
+  parsing in `git am`, which remains an open problem with no obvious
   backward-compatible solution. But it produced two concrete
   improvements that were accepted and are now in `master`: a CAVEATS
   section in the documentation for git-am(1), git-format-patch(1), and
@@ -258,11 +258,11 @@ This edition covers what happened during the months of February and March 2026.
 
   The thread also served as a useful reminder that this problem is not
   limited to email workflows: any project that generates patches from
-  Git commits using git-format-patch(1) and applies them with patch(1)
-  or git-am(1) is exposed to it. The practical advice for authors is
+  Git commits using `git format-patch` and applies them with `patch`
+  or `git am` is exposed to it. The practical advice for authors is
   simple: if you include diffs in commit messages for illustrative
   purposes, make sure to indent them consistently, and be aware that
-  even that does not protect you from patch(1).
+  even that does not protect you from `patch`.
 
 ## Developer Spotlight: Olamide Caleb Bello
 
@@ -276,7 +276,7 @@ As always, we welcome your thoughts and feedback!_
 
   I’m Olamide Caleb Bello, a software engineer based in Nigeria. I studied
   Economics, but I’ve always been curious about technology and how
-  Systems work behind the scenes. That curiosity led me to start teaching
+  systems work behind the scenes. That curiosity led me to start teaching
   myself web development, and over time I found myself drawn more
   towards backend and systems-oriented work.