From c4a9fa996867e48223a4fe327cb3e9455de2302b Mon Sep 17 00:00:00 2001 From: Kaartic Sivaraam Date: Fri, 27 Mar 2026 01:17:22 +0530 Subject: [PATCH 01/19] rn-133: add interview with Olamide Caleb Bello --- rev_news/drafts/edition-133.md | 210 ++++++++++++++++++++++++++++++++- 1 file changed, 207 insertions(+), 3 deletions(-) diff --git a/rev_news/drafts/edition-133.md b/rev_news/drafts/edition-133.md index 6864fa8be..ba0b0ec7d 100644 --- a/rev_news/drafts/edition-133.md +++ b/rev_news/drafts/edition-133.md @@ -29,9 +29,213 @@ This edition covers what happened during the months of February and March 2026. ### Support --> - +## Developer Spotlight: Olamide Caleb Bello + +_Editor’s note: This edition features a retrospective interview with a +contributor who contributed to Git through a mentoring program. +We hope the reflections shared by the Outreachy contributor will +provide an insightful perspective that benefits the community. +As always, we welcome your thoughts and feedback!_ + +* **Who are you and what do you do?** + + 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 + myself web development, and over time I found myself drawn more + towards backend and systems-oriented work. + + I became especially interested in understanding how complex tools are + built and maintained, which led me to open source. I contributed to Git + as part of the Outreachy program, where I got to work on improving parts + of Git’s internal workflows. + + These days, I enjoy working on tools that make development smoother + for others, and I’m particularly interested in open source and + distributed systems. + +* **How did you initially become interested in contributing to Git, + and what motivated you to choose it as your Outreachy project?** + + I initially saw Git as just a tool I needed to get my work done. For a + long time, my workflow was basically just `git add`, `git commit`, `git push`, + and `git pull`, without thinking much about what was happening underneath. + That started to change when I ran into some particularly messy merge conflicts + that forced me to slow down and really question how Git was managing + history and combining changes. + + Around the same time, I was becoming more interested in systems in + general, thinking about tools like the kernel, systemd, and Git + itself, and how they work under the hood. That experience pushed me to + look deeper into Git’s internals, and I quickly realized how much + depth there was beneath the surface. + + When I came across the Outreachy project, choosing Git felt natural, I + wanted to challenge myself and contribute to a tool I had used for + years but didn’t fully understand, while learning from experienced + maintainers. + +* **How do you feel your contribution has impacted the Git community + or the broader open source ecosystem?** + + [My work](https://cloobtech.hashnode.dev/beginning-my-outreachy-opensource-internship-at-git-overview-and-project-description) + focused on reducing Git’s reliance on global state by refactoring + repository-specific variables into a more localized structure. Each repository + instance now manages its own configuration independently, improving modularity + and reducing the risk of cross-repository issues. + + Through this work, I came to appreciate how changes at this level contribute to + Git’s long-term direction, particularly efforts to make it more reusable as a + library. Even though these changes aren’t directly visible to users, they make + the system safer and easier to extend. + + Being part of that process gave me a deeper respect for the level of thought + and the care that goes into maintaining Git. + +* **Is there any aspect of Git that you now see differently after + having contributed to it?** + + Before contributing, I thought Git was just a bunch of commands I + typed every day. Working on it showed me a whole hidden world, + how configurations are saved and read, how each repository handles + its own settings, and what the index is really doing behind the scenes. + Some of it was so intricate I almost felt like Git was trolling me! + + Seeing all this up close turned what felt like a simple tool into a + carefully designed system, and it gave me a much deeper appreciation + for the thought and care behind every command. + +* **How do you balance your contributions with other responsibilities + like work or school?** + + At the moment, I’m not tied to a full-time job or school, but I spend a lot + of time learning new tech and doing freelance work. I usually dedicate small, + focused sessions to Git contributions, sometimes just an hour here or there, + and it’s surprising how much progress you can make that way. This rhythm lets + me keep learning, experimenting, and contributing without feeling overwhelmed. + +* **Can you share how Outreachy helped enhance your technical and + non-technical skills (like communication, project management, + etc.)?** + + Outreachy was a huge growth opportunity for me, both technically and personally. + On the technical side, I deepened my understanding of Git internals, learned to + work effectively in a large C codebase, and tackled complex refactoring of core + systems. On the non-technical side, I honed my communication skills by engaging + actively on the Git mailing list, responding to feedback, and documenting my + work clearly for others. The experience also helped me improve project + discipline, learning how to plan and iterate on tasks in a structured way. + +* **What was your biggest takeaway or learning from Outreachy that + you now apply regularly in your work?** + + My biggest takeaway from Outreachy was learning how even small, careful changes + can have a big impact in a large system like Git. During Outreachy, for even + the tiniest change, I had to run over 32,000 test cases just to be + sure it wouldn’t break anything! I approach my work by breaking tasks into + smaller steps, testing thoroughly, and thinking through the consequences + before making changes. This mindset has become a regular part of how I work, + whether I’m contributing to open source or building my own projects. + +* **What was the biggest challenge you faced during your contributions + to Git, and how did you overcome it?** + + The toughest part of contributing to Git was navigating its huge and complex + C codebase. I had to wrap my head around global variables, repository-specific + state, and how configs were stored and read. At first, it felt overwhelming, + and I constantly worried that even a small change might break something. + + I overcame this by tackling one piece at a time, reading the code carefully, + testing thoroughly, and admittedly, disturbing my mentors quite a bit! 😂 I’m + especially grateful to Christian Couder and Usman Akinyemi, who guided me + patiently. Christian taught me how to ask questions properly, showed me how to + debug effectively, and always encouraged me to think through problems step by + step. Usman was equally supportive, often checking in and joining coding + sessions with me. Both helped me understand Git’s internal architecture and + gave me the confidence to contribute safely and effectively. + +* **Have you thought about mentoring new GSoC / Outreachy students?** + + Yes, I have thought about mentoring future GSoC or Outreachy students. Since I’m + still relatively new to open source myself, I want to focus on contributing and + learning for now. However, I do hope to co-mentor in the next Outreachy program, + sharing what I’ve learned and helping others navigate the experience. + +* **If you could get a team of expert developers to work full time on + something in Git for a full year, what would it be?** + + If I had a team of expert developers working full time on Git for a year, I + would focus on further improving its modularity and internal architecture. + My goal would be to make Git easier to embed and reuse as a library, reducing + reliance on global state and improving the safety of multi-repository + operations. + + This would not only make Git more maintainable for contributors but also open + up new possibilities for other projects to integrate Git functionality + more easily. + +* **If you could remove something from Git without worrying about + backwards compatibility, what would it be?** + + If I could remove anything from Git without worrying about backwards + compatibility, I’d simplify some of the legacy parts of its internal state. + These older structures can be confusing and tricky to work with, and removing + them would make Git’s internals cleaner and easier to reason about. + +* **What upcoming features or changes in Git are you particularly + excited about?** + + I’m particularly excited about Git’s ongoing libification efforts, which make + it easier for other projects to embed and reuse Git functionality. Changes that + reduce global state and improve repository isolation also excite me, because + they make multi-repository operations safer and Git’s internals easier to work + with. I’m curious to see how these improvements will open up new possibilities + for both contributors and external tools that rely on Git. + +* **What is your favorite Git-related tool/library, outside of Git + itself?** + + I’d say my favorite Git-related tool is `gitingest`. It’s really handy for + exploring repositories programmatically and testing workflows. I’ve found it + especially useful while learning Git internals. + +* **What is your toolbox for interacting with the mailing list and for + development of Git?** + + I mainly use `git send-email` to submit patches, read threads on + [lore.kernel.org/git](https://lore.kernel.org/git), and reply via + Gmail. This setup helps me follow discussions and iterate on my + contributions smoothly. + + +* **How do you envision your own involvement with Git or other open + source projects in the future?** + + I’m here to stay in open source. I want to keep contributing to Git and other + projects, learning as I go, taking on bigger challenges, and helping new + contributors find their footing. Open source has become a big part of how I + grow as a developer, and I hope to keep giving back for years to come. + +* **What is your advice for people who want to start Git development? + Where and how should they start?** + + My advice for anyone starting Git development is to begin small and be curious. + A great resource I found helpful is the [MyFirstContribution](https://git-scm.com/docs/MyFirstContribution) + document. Start by reading the guides, experimenting locally, and submitting + small patches. Interacting with the mailing list, asking questions, and iterating + on feedback will help you learn and grow as a contributor. + +* **Would you recommend other students or contributors to participate + in the GSoC, Outreachy or other mentoring programs, working on + Git? Why? Do you have advice for them?** + + Absolutely, I would recommend programs like GSoC or Outreachy for anyone + interested in Git or open source. These programs provide structured mentorship, + exposure to real-world projects, and the chance to learn directly from + experienced developers. My advice is to start small, be curious, ask questions, + and don’t be afraid to iterate on feedback. Every contribution, no matter how + minor it may seem, is a valuable learning experience. + ## Other News From 4efd03c267f1f5f49c346325639310629b5b6b91 Mon Sep 17 00:00:00 2001 From: Christian Couder Date: Sun, 29 Mar 2026 16:22:58 +0200 Subject: [PATCH 02/19] rn-133: add releases --- rev_news/drafts/edition-133.md | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) diff --git a/rev_news/drafts/edition-133.md b/rev_news/drafts/edition-133.md index ba0b0ec7d..466df15aa 100644 --- a/rev_news/drafts/edition-133.md +++ b/rev_news/drafts/edition-133.md @@ -253,6 +253,35 @@ __Git tools and sites__ ## Releases ++ Git for Windows [v2.52.0(2)](https://github.com/git-for-windows/git/releases/tag/v2.52.0.windows.2), +[v2.51.2(2)](https://github.com/git-for-windows/git/releases/tag/v2.51.2.windows.2), +[v2.53.0(2)](https://github.com/git-for-windows/git/releases/tag/v2.53.0.windows.2) ++ Bitbucket Data Center [10.2](https://confluence.atlassian.com/bitbucketserver/release-notes-872139866.html) ++ Gerrit Code Review [3.11.10](https://www.gerritcodereview.com/3.11.html#31110), +[3.11.9](https://www.gerritcodereview.com/3.11.html#3119), +[3.12.5](https://www.gerritcodereview.com/3.12.html#3125), +[3.12.6](https://www.gerritcodereview.com/3.12.html#3126), +[3.13.4](https://www.gerritcodereview.com/3.13.html#3134), +[3.13.5](https://www.gerritcodereview.com/3.13.html#3135), +[3.14.0-rc0](https://www.gerritcodereview.com/3.14.html#3140) ++ GitHub Enterprise [3.20.0](https://docs.github.com/enterprise-server@3.20/admin/release-notes#3.20.0), +[3.19.4](https://docs.github.com/enterprise-server@3.19/admin/release-notes#3.19.4), +[3.18.7](https://docs.github.com/enterprise-server@3.18/admin/release-notes#3.18.7), +[3.17.13](https://docs.github.com/enterprise-server@3.17/admin/release-notes#3.17.13), +[3.16.16](https://docs.github.com/enterprise-server@3.16/admin/release-notes#3.16.16), +[3.15.20](https://docs.github.com/enterprise-server@3.15/admin/release-notes#3.15.20), +[3.14.25](https://docs.github.com/enterprise-server@3.14/admin/release-notes#3.14.25) ++ GitLab [18.10.1, 18.9.3, 18.8.7](https://about.gitlab.com/releases/2026/03/25/patch-release-gitlab-18-10-1-released/), +[18.10](https://about.gitlab.com/releases/2026/03/19/gitlab-18-10-released/), +[18.9.2, 18.8.6, 18.7.6](https://about.gitlab.com/releases/2026/03/11/patch-release-gitlab-18-9-2-released/) ++ GitKraken [11.10.0](https://help.gitkraken.com/gitkraken-desktop/current/) ++ GitHub Desktop [3.5.6](https://desktop.github.com/release-notes/) ++ Garden [2.6.0](https://github.com/garden-rs/garden/releases/tag/v2.6.0) ++ Git Cola [4.18.2](https://github.com/git-cola/git-cola/releases/tag/v4.18.2), +[4.18.1](https://github.com/git-cola/git-cola/releases/tag/v4.18.1), +[4.18.0](https://github.com/git-cola/git-cola/releases/tag/v4.18.0) ++ GitButler [0.19.6](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.19.6), +[0.19.5](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.19.5) ## Credits From ecb8cce5bbda76b6ba8a551d9eafea76d11929c0 Mon Sep 17 00:00:00 2001 From: Christian Couder Date: Sun, 29 Mar 2026 16:29:56 +0200 Subject: [PATCH 03/19] rn-133: add Olamide Caleb Bello among the helpers --- rev_news/drafts/edition-133.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/rev_news/drafts/edition-133.md b/rev_news/drafts/edition-133.md index 466df15aa..31d40a11b 100644 --- a/rev_news/drafts/edition-133.md +++ b/rev_news/drafts/edition-133.md @@ -207,7 +207,6 @@ As always, we welcome your thoughts and feedback!_ Gmail. This setup helps me follow discussions and iterate on my contributions smoothly. - * **How do you envision your own involvement with Git or other open source projects in the future?** @@ -290,4 +289,4 @@ Christian Couder <>, Jakub Narębski <>, Markus Jansen <> and Kaartic Sivaraam <> -with help from XXX. +with help from Olamide Caleb Bello. From 1d69c1a8b4cab2a3bd8fa654355c7a9a5ae05bd7 Mon Sep 17 00:00:00 2001 From: Christian Couder Date: Mon, 30 Mar 2026 12:12:11 +0200 Subject: [PATCH 04/19] rn-133: add git-am and commit messages article --- rev_news/drafts/edition-133.md | 239 ++++++++++++++++++++++++++++++++- 1 file changed, 237 insertions(+), 2 deletions(-) diff --git a/rev_news/drafts/edition-133.md b/rev_news/drafts/edition-133.md index 31d40a11b..65a753518 100644 --- a/rev_news/drafts/edition-133.md +++ b/rev_news/drafts/edition-133.md @@ -25,9 +25,244 @@ This edition covers what happened during the months of February and March 2026. ### Reviews --> - + ++ [git-am applies commit message diffs](https://lore.kernel.org/git/bcqvh7ahjjgzpgxwnr4kh3hfkksfruf54refyry3ha7qk7dldf@fij5calmscvm) + +On February 6, 2026, Matthias Beyer forwarded to the Git mailing list a +surprising warning that had just circulated on Mastodon: + +> PSA: Did you know that it's **unsafe** to put code diffs into your +> commit messages? +> +> Such diffs will be applied by patch(1) (also git-am(1)) as part of +> the code change! +> +> This is how a sleep(1) made it into i3 4.25-2 in Debian unstable. + +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 +in the commit message was applied as actual code, sneaking a spurious +`sleep(1)` 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` 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 +the boundary between the two: + +- a line consisting of only three dashes (`---`), +- a line beginning with `diff -`, or +- 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` +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` 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` a hand-typed email containing a GNU diff, and it produced the +expected commit. + +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 +problem (in 2015, 2022, and 2024). The stream is simply ambiguous by +design. Even the `---` marker itself cannot be used to robustly split +things, since `---` on a line by itself is a valid diff hunk line +indicating that the string `--` was removed from a file. + +Matthias proposed parsing from the end of the email rather than from +the top. Peff replied that this would still be ambiguous for the same +reasons, and would introduce new corner cases. + +Jacob Keller noted early on that the issue was certainly surprising but +that he was unsure it constituted a security attack vector, since +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 +commit message. + +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` were fixed to +require indented diffs, it would only partially mitigate the problem, +because `patch(1)` (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`. + +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 +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` does have a `--attach` +option which puts the message and the patch in separate MIME parts — +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` 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` 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` +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 `---`, +it would not be inserted into the commit message when applied. + +Peff replied that this was trickier than it sounded: the new marker +would have to be something that could never appear legitimately in a +commit message, and both sides would need to complain if they saw +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` 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. + +Peff also proposed a simpler receiver-side improvement: a +`git am --strict` mode that would always require a `---` separator +before the diff, on the assumption that well-formatted patches from Git +always have one. This would not help with diffs that legitimately +appear before the `---`, but would eliminate the most common accidental +cases. + +None of these ideas led to an immediate implementation, as they all +involve backward compatibility tradeoffs that would need careful +thought. + +On February 8, Kristoffer sent a documentation patch titled "doc: add +caveat about roundtripping format-patch" which introduced a new +`Documentation/format-patch-caveats.adoc` file explaining the +behavior. The caveat was designed to be included in the documentation +for `git-am`, `git-format-patch`, and `git-send-email`. + +Junio reviewed +[version 1](https://lore.kernel.org/git/format-patch_caveats.281@msgid.xyz) +and offered a correction to the wording: rather than saying that an +unindented diff in the commit message "will not only cut the message +short but cause that very diff to be applied, along with the patch in +the patch section," Junio noted that the outcome is not so +deterministic. The diff in the commit message might get applied, or +the patch machinery might trip on something and fail outright. He also +flagged that the space after the `---` in the cover letter was +inconsistent with the project's conventions. + +Phillip Wood reviewed the patch and found the mention of +`git-send-email` a bit distracting, since that command merely runs +`git-format-patch` and does not do any formatting itself. He also +suggested wording improvements: replacing "One might want to use [...] +patch(1)" with "Given these limitations, one might be tempted to [...]". + +Kristoffer incorporated all of this in +[version 2](https://lore.kernel.org/git/V2_format-patch_caveats.34b@msgid.xyz), +which dropped the `git-send-email` mention from the introductory +paragraph (while keeping the CAVEATS section in its documentation, for +users who encounter it there), removed example code blocks in favor of +clearer prose, and used the list of message-terminating patterns +already present in `git-am`'s documentation. Junio reviewed it and +queued it with the comment "Nicely written." + +A third version, +[version 3](https://lore.kernel.org/git/pull.2220.v3.git.git.1772559813151.gitgitgadget@gmail.com), +was submitted and received Junio's approval to go to `next`. + +Meanwhile, Phillip had observed that since the parsing cannot be fixed, +"perhaps we should update our sample `commit-msg` hook to reject +messages that will cause problems." On February 7, he sent a 3-patch +series titled "commit-msg.sample: reject messages that would confuse +`git am`". The series: + +1. Added a `.gitattributes` rule for sample hooks (which are shell + scripts but have `.sample` extensions). +2. Extended the sample `commit-msg` hook to scan the body of the commit + 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` to silently truncate the commit + message. + +Peff reacted with measured skepticism to patch 3 in +[version 1](https://lore.kernel.org/git/cover.1770476279.git.phillip.wood@dunelm.org.uk): +he and Junio both pointed out that they themselves sometimes use `---` +intentionally in commit messages to add notes that will appear in the +formatted patch email but not end up in the final commit message when +applied. Junio explained the trick: "when I know what I want to write +below the three-dash lines, I would commit with `---` and additional +notes below it, so that I do not forget during format-patch. When the +commit is turned into a patch email [...] `am` cuts at the first one, +and `apply` knows that the garbage lines at front, including +three-dash lines, do not matter until it sees `^diff`, this works out +perfectly well." + +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 +[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 +header and so does not go through the patch boundary detection), skips +lines below a scissors line, and handles the `core.commentChar` and +`core.commentString` configuration options for determining which lines +are comments. Junio reviewed version 2 with detailed questions about +the scissors-line logic. + +Kristoffer verified that version 2 worked with `git commit +--cleanup=scissors --verbose` and was satisfied. + +The discussion did not lead to a fundamental fix to the ambiguous +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`, `git-format-patch`, and +`git-send-email` spelling out exactly how commit messages can +inadvertently interfere with patch application, and an enhanced sample +`commit-msg` hook that rejects messages containing unindented diffs. + +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` and applies them with `patch(1)` +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)`. ## Developer Spotlight: Olamide Caleb Bello From 3b9c730b9233e5d9eaff3b4421672e0fb3d055e7 Mon Sep 17 00:00:00 2001 From: Kristoffer Haugsbakk Date: Mon, 30 Mar 2026 17:03:24 +0200 Subject: [PATCH 05/19] rn-133: fix link to v3 of topic kh/doc-am-format-sendmail --- rev_news/drafts/edition-133.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rev_news/drafts/edition-133.md b/rev_news/drafts/edition-133.md index 65a753518..f447f6847 100644 --- a/rev_news/drafts/edition-133.md +++ b/rev_news/drafts/edition-133.md @@ -201,7 +201,7 @@ already present in `git-am`'s documentation. Junio reviewed it and queued it with the comment "Nicely written." A third version, -[version 3](https://lore.kernel.org/git/pull.2220.v3.git.git.1772559813151.gitgitgadget@gmail.com), +[version 3](https://lore.kernel.org/git/V3_format-patch_caveats.354@msgid.xyz), was submitted and received Junio's approval to go to `next`. Meanwhile, Phillip had observed that since the parsing cannot be fixed, From 09ed58da2b92402825a0b617659895147502fba9 Mon Sep 17 00:00:00 2001 From: Bruno Brito Date: Tue, 31 Mar 2026 10:49:13 +0100 Subject: [PATCH 06/19] Add light reading + Tower releases --- rev_news/drafts/edition-133.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/rev_news/drafts/edition-133.md b/rev_news/drafts/edition-133.md index f447f6847..b04d32c69 100644 --- a/rev_news/drafts/edition-133.md +++ b/rev_news/drafts/edition-133.md @@ -478,6 +478,8 @@ __Various__ __Light reading__ ++ Automate Your Code with GitHub Actions ([Part 1](https://www.git-tower.com/blog/github-actions-fundamentals) and [Part 2](https://www.git-tower.com/blog/github-actions-events-and-triggers)) by Bas Steins on Tower's Blog. + @@ -516,6 +518,8 @@ __Git tools and sites__ [4.18.0](https://github.com/git-cola/git-cola/releases/tag/v4.18.0) + GitButler [0.19.6](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.19.6), [0.19.5](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.19.5) ++ Tower for Mac [16.0 (Beta)](https://www.git-tower.com/blog/tower-mac-16) ++ Tower for Windows [11.2](https://www.git-tower.com/release-notes?show_tab=release-notes) ## Credits From 8307c496ce06e1a4c06a95692e3ecbd785b44914 Mon Sep 17 00:00:00 2001 From: Christian Couder Date: Tue, 31 Mar 2026 14:30:22 +0200 Subject: [PATCH 07/19] rn-133: add Bruno Brito among the helpers --- rev_news/drafts/edition-133.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rev_news/drafts/edition-133.md b/rev_news/drafts/edition-133.md index b04d32c69..02f033154 100644 --- a/rev_news/drafts/edition-133.md +++ b/rev_news/drafts/edition-133.md @@ -528,4 +528,4 @@ Christian Couder <>, Jakub Narębski <>, Markus Jansen <> and Kaartic Sivaraam <> -with help from Olamide Caleb Bello. +with help from Olamide Caleb Bello and Bruno Brito. From 5cc1a028335e8b52e539f58e66ba061da93ee969 Mon Sep 17 00:00:00 2001 From: Kristoffer Haugsbakk Date: Mon, 30 Mar 2026 17:15:57 +0200 Subject: [PATCH 08/19] rn-133: change command mentions to man page references MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit We don’t need to use verbatim markup for commands; we can use man page (section 1) references instead. And those that are referenced in such a way already don’t need this markup. Note that `sleep(1)` is literally a C function call, so that needs to be left alone. Only change the style in “Discussions” in order to not infringe on the style chosen for the “Developer Spotlight” section. Also don’t change anything that is inside quotations (quote block/inline). --- rev_news/drafts/edition-133.md | 64 +++++++++++++++++----------------- 1 file changed, 32 insertions(+), 32 deletions(-) diff --git a/rev_news/drafts/edition-133.md b/rev_news/drafts/edition-133.md index 65a753518..5d0af7b0e 100644 --- a/rev_news/drafts/edition-133.md +++ b/rev_news/drafts/edition-133.md @@ -42,13 +42,13 @@ surprising warning that had just circulated on Mastodon: 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(1), 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 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` parses +To understand why this happens, it helps to know how git-am(1) 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 @@ the boundary between the two: - 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` +after is fed to the patch application machinery. Crucially, git-am(1) 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` was +as "Peff") quickly explained in reply to Matthias, git-am(1) 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` a hand-typed email containing a GNU diff, and it produced the +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 expected commit. -This historical context also explained why `git-am` is notoriously +This historical context also explained why git-am(1) 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 @@ -96,19 +96,19 @@ 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 commit message. -Florian Weimer wondered whether the `git-format-patch` output was +Florian Weimer wondered whether the git-format-patch(1) 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` were fixed to +Jakob Haufe added an important nuance: even if git-am(1) were fixed to require indented diffs, it would only partially mitigate the problem, -because `patch(1)` (which many distributions use to apply upstream +because patch(1) (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 +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`. +had in fact been triggered by patch(1), not git-am(1). Kristoffer Haugsbakk synthesized this into a clear summary of the situation and immediately proposed documenting it. @@ -116,31 +116,31 @@ 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(1). 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` does have a `--attach` +Peff observed the irony that git-format-patch(1) does have a `--attach` option which puts the message and the patch in separate MIME parts — -making them unambiguous in principle. However, `git-mailinfo` (which -powers `git-am` under the hood) decodes both parts into a single +making them unambiguous in principle. However, git-mailinfo(1) (which +powers git-am(1) 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` could at least detect the ambiguity and bail by +unambiguous, git-am(1) 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` would produce output that new versions of `git-am` +git-format-patch(1) would produce output that new versions of git-am(1) 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` +marker after the `---` separator, so that old versions of git-am(1) 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 @@ commit message, and both sides would need to complain if they saw 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` received the +otherwise be ambiguous. This way, if an older git-am(1) 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. @@ -172,7 +172,7 @@ On February 8, Kristoffer sent a documentation patch titled "doc: add caveat about roundtripping format-patch" which introduced a new `Documentation/format-patch-caveats.adoc` file explaining the behavior. The caveat was designed to be included in the documentation -for `git-am`, `git-format-patch`, and `git-send-email`. +for git-am(1), git-format-patch(1), and git-send-email(1). Junio reviewed [version 1](https://lore.kernel.org/git/format-patch_caveats.281@msgid.xyz) @@ -186,18 +186,18 @@ flagged that the space after the `---` in the cover letter was inconsistent with the project's conventions. Phillip Wood reviewed the patch and found the mention of -`git-send-email` a bit distracting, since that command merely runs -`git-format-patch` and does not do any formatting itself. He also +git-send-email(1) a bit distracting, since that command merely runs +git-format-patch(1) and does not do any formatting itself. He also suggested wording improvements: replacing "One might want to use [...] patch(1)" with "Given these limitations, one might be tempted to [...]". Kristoffer incorporated all of this in [version 2](https://lore.kernel.org/git/V2_format-patch_caveats.34b@msgid.xyz), -which dropped the `git-send-email` mention from the introductory +which dropped the git-send-email(1) mention from the introductory paragraph (while keeping the CAVEATS section in its documentation, for users who encounter it there), removed example code blocks in favor of clearer prose, and used the list of message-terminating patterns -already present in `git-am`'s documentation. Junio reviewed it and +already present in git-am(1)'s documentation. Junio reviewed it and queued it with the comment "Nicely written." A third version, @@ -216,7 +216,7 @@ series titled "commit-msg.sample: reject messages that would confuse 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` to silently truncate the commit + body, which would cause git-am(1) to silently truncate the commit message. Peff reacted with measured skepticism to patch 3 in @@ -248,21 +248,21 @@ Kristoffer verified that version 2 worked with `git commit --cleanup=scissors --verbose` and was satisfied. The discussion did not lead to a fundamental fix to the ambiguous -parsing in `git-am`, which remains an open problem with no obvious +parsing in git-am(1), 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`, `git-format-patch`, and -`git-send-email` spelling out exactly how commit messages can +section in the documentation for git-am(1), git-format-patch(1), and +git-send-email(1) spelling out exactly how commit messages can inadvertently interfere with patch application, and an enhanced sample `commit-msg` hook that rejects messages containing unindented diffs. 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` and applies them with `patch(1)` -or `git-am` is exposed to it. The practical advice for authors is +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 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(1). ## Developer Spotlight: Olamide Caleb Bello From 768cb6b6ac3d7833e580923fc1fb6c6d91306d44 Mon Sep 17 00:00:00 2001 From: Kristoffer Haugsbakk Date: Mon, 30 Mar 2026 17:44:14 +0200 Subject: [PATCH 09/19] rn-133: fix verb --- rev_news/drafts/edition-133.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rev_news/drafts/edition-133.md b/rev_news/drafts/edition-133.md index 5d0af7b0e..b4ef6717a 100644 --- a/rev_news/drafts/edition-133.md +++ b/rev_news/drafts/edition-133.md @@ -101,7 +101,7 @@ 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) were fixed to +Jakob Haufe added an important nuance: even if git-am(1) was fixed to require indented diffs, it would only partially mitigate the problem, because patch(1) (which many distributions use to apply upstream fixes to packages) is even more permissive. It will strip a consistent From d1391c40911a2aae612b9b2a89b73ccfb5c27b27 Mon Sep 17 00:00:00 2001 From: Christian Couder Date: Tue, 31 Mar 2026 19:05:25 +0200 Subject: [PATCH 10/19] rn-133: add Kristoffer Haugsbakk among the helpers --- rev_news/drafts/edition-133.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/rev_news/drafts/edition-133.md b/rev_news/drafts/edition-133.md index 2912f15dc..13cf7fec5 100644 --- a/rev_news/drafts/edition-133.md +++ b/rev_news/drafts/edition-133.md @@ -528,4 +528,5 @@ Christian Couder <>, Jakub Narębski <>, Markus Jansen <> and Kaartic Sivaraam <> -with help from Olamide Caleb Bello and Bruno Brito. +with help from Olamide Caleb Bello, Bruno Brito and +Kristoffer Haugsbakk. From c7b5565026fc79d050ab9ef20b26bca8ea570428 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jakub=20Nar=C4=99bski?= Date: Wed, 1 Apr 2026 01:54:00 +0200 Subject: [PATCH 11/19] rn-133: Add links to news, articles, sites, and tools --- rev_news/drafts/edition-133.md | 298 ++++++++++++++++++++++++++++++++- 1 file changed, 297 insertions(+), 1 deletion(-) diff --git a/rev_news/drafts/edition-133.md b/rev_news/drafts/edition-133.md index 13cf7fec5..c935ad593 100644 --- a/rev_news/drafts/edition-133.md +++ b/rev_news/drafts/edition-133.md @@ -474,9 +474,187 @@ As always, we welcome your thoughts and feedback!_ ## Other News __Various__ - ++ [The forge is our new home.](https://communityblog.fedoraproject.org/the-forge-is-our-new-home/) + by Tomáš Hrčka on Fedora Community Blog.
+ After a full year of preparation, the Community Linux Engineering (CLE) team + announced that [Fedora Forge](https://forge.fedoraproject.org/explore/organizations), + powered by [Forgejo](https://forgejo.org/), is ready for use. + If you own a project at [pagure.io](https://pagure.io/), + you must migrate out of it before June 2026; + [How to Migrate Repository from Pagure](https://docs.fedoraproject.org/en-US/forge-documentation/migration/pagure_repository/) + guide is there to help with this task. + Note that Fedora Forge is narrower in scope than pagure\.io; + it is provisioned to host the code, documentation, and tooling + that directly build, manage, and govern the Fedora Project. + Personal projects and general upstream development does not belong on Fedora Forge. ++ [GNOME GitLab Redirecting Some Git Traffic To GitHub For Reducing Costs](https://www.phoronix.com/news/GNOME-GitHub-GitLab-Redirect) + by Michael Larabel in GNOME on Phoronix. ++ [Radicle: Disclosure of Replay Attack Vulnerability in Signed References](https://radicle.xyz/2026/03/30/disclosure-of-vulnerability-in-signed-references) + + [Radicle](https://radicle.xyz) is a peer-to-peer, local-first + code collaboration stack built on Git. + It was first mentioned in [Git Rev News Edition #49](https://git.github.io/rev_news/2019/03/20/edition-49/) + and most recently in [edition #131](https://git.github.io/rev_news/2026/01/31/edition-131/).
+ Compare [Tangled](https://tangled.org/) (built on top of AT Protocol), + [Grasp](https://ngit.dev/grasp/) and [`git str`](https://github.com/fiatjaf/gitstr) (built on top of Nostr), and + [`git-ssb`](https://scuttlebot.io/apis/community/git-ssb.html) (built on top of Secure-ScuttleButt (SSB); though SSB ecosystem contracted, with latest news from 2024). ++ [b4's Review TUI With AI Integration Nearing Pre-Alpha Release](https://www.phoronix.com/news/b4-review-nears-pre-alpha) + by Michael Larabel in Linux Kernel section on Phoronix. __Light reading__ ++ [The Comforting Lie Of SHA Pinning](https://www.vaines.org/posts/2026-03-24-the-comforting-lie-of-sha-pinning/) + by Aiden Vaines on Vaines\.org. + The recommendation to _pin your dependencies_ in GitHub Actions + translates to using commit SHAs, not tags - which can be moved + (though GitHub already has optional ‘Make tags immutable’ feature). + However, GitHub Actions does not meaningfully validate that + the commit SHA you reference belongs to the repository you think it does: + it can belong to a hostile fork. ++ [Git Remote Helpers](https://nesbitt.io/2026/03/18/git-remote-helpers.html): + how to create `git-remote-swh` that would let you `git clone` from a [SWHID](https://www.swhid.org/), + pulling source code directly from [Software Heritage](https://www.softwareheritage.org/)’s archive + by content hash rather than by URL. + Written by Andrew Nesbitt on his blog. + Also lists built-in remote helpers, and lists third-party helpers: + for cloud and object storage, for content-addressed storage, + for encryption, for VCS bridges, + for P2P and decentralised (though this list was missing `git-remote-rad` for Radicle), + for a different transport layer, for blockchain, for other storage backends. ++ [Git Bayesect](https://hauntsaninja.github.io/git_bayesect.html) + by Shantanu Jain (@hauntsaninja) on his blog. + It describes the idea behind [git bayesect](https://github.com/hauntsaninja/git_bayesect), + which is a generalisation of `git bisect` that uses Bayesian inference to solve + the problem of flaky, non-deterministic tests. ++ [Git Tricks with Tri and Difft](https://nabeelvalley.co.za/blog/2026/26-03/tri-x-git-tricks/) + by Nabeel Valley on their blog. + + [Tri](https://github.com/sftsrv/tri) is TUI interactive directory tree browser, + and [difft, or Difftastic](https://difftastic.wilfred.me.uk/introduction.html) + is a structural diff tool that understands syntax. + Difftastic was first mentioned in [Git Rev News Edition #86](https://git.github.io/rev_news/2022/04/30/edition-86/), + and most recently in [Edition #131](https://git.github.io/rev_news/2026/01/31/edition-131/). ++ [Awesome Git Diffs with Delta, fzf and a Little Shell Scripting](https://nickjanetakis.com/blog/awesome-git-diffs-with-delta-fzf-and-a-little-shell-scripting) + by Nick Janetakis on his blog. + + [delta](https://dandavison.github.io/delta/) (from 'git-delta' package) + is a syntax-highlighting pager for git, diff, grep, and blame output, + first mentioned in [Git Rev News Edition #9](https://git.github.io/rev_news/2015/11/11/edition-9/), + and most recently in [Edition #131](https://git.github.io/rev_news/2026/01/31/edition-131/).
+ [fzf](https://github.com/junegunn/fzf) is a command-line fuzzy finder, + first mentioned directly in [Git Rev News Edition #74](https://git.github.io/rev_news/2021/04/30/edition-74/) + (in passing first in [Edition #64](https://git.github.io/rev_news/2020/06/25/edition-64/)), + and most recently in [Edition #130](https://git.github.io/rev_news/2025/12/31/edition-130/). ++ [Build Git helpers from scratch with Bash and fzf](https://oliviac.dev/blog/build-git-helpers-bash-fzf/) and + [Improve your Git CLI experience with Git aliases, delta, and custom functions](https://oliviac.dev/blog/customize-git-cli-aliases-delta/) + by Olivia Coumans on her blog. ++ [Taming a 486MB Git Repo](https://hsps.in/post/taming-a-486mb-git-repo/) + (with source code taking 6MB) by Harisankar P S on his HsPS\.in blog. ++ [CodeCity: Turning a Codebase into a Skyline](https://verial.xyz/posts/codecity), + about a polyglot (multi-language) CodeCity visualizer built in Rust, + rendering codebases as interactive 3D cities. In this tool, modules are shown + as buildings, grouped together in districts corresponding to top-level packages + (squarified treemap), with footprint corresponding to size in lines of code, + height corresponding to complexity, and color corresponding to "health". + Follows from [Legibility: A Scaling Bottleneck of the Agentic Era](https://verial.xyz/essays/legibility) essay. ++ [“Use git worktrees,” they said. “It’ll be fun!” they said.](https://daveschumaker.net/use-git-worktrees-they-said-itll-be-fun-they-said/) + by Dave Schumaker on his blog. + This posts describes problem with often used solutions like + symlinked `node_modules` or `.venv` directories, Yarn’s hardlinks-global mode, + APFS Copy-on-Write (`cp -c`) - which is also supported by other filesystems. + Proposes keeping a fixed pool of 6 worktree slots, and recycling them as needed. ++ [Direnv is All You Need to Parallelize Agentic Programming with Git Worktrees](https://waldencui.com/post/direnv_is_all_you_need_to_parallelize_claude_code_with_git_worktrees/) + by Walden Cui on The Search Blog.
+ See also, for example: + + [I Built workz: The Zoxide for Git Worktrees That Finally Fixes .env + node\_modules Hell in 2026](https://dev.to/rohansx/i-built-workz-the-zoxide-for-git-worktrees-that-finally-fixes-env-nodemodules-hell-in-2026-2dpj), + mentioned in [Git Rev News Edition #132](https://git.github.io/rev_news/2026/02/28/edition-132/). + + [Git Worktrees with Claude Code, Laravel, and Herd](https://gause.cz/blog/git-worktrees-with-claude-code-laravel-and-herd/), + mentioned in [Git Rev News Edition #132](https://git.github.io/rev_news/2026/02/28/edition-132/). + + [Why You Should Be Using Git Worktrees](https://blog.randombits.host/why-you-should-be-using-git-worktrees/), + mentioned in [Git Rev News Edition #129](https://git.github.io/rev_news/2025/11/30/edition-129/). + + [tree-me: Because git worktrees shouldn't be a chore](https://haacked.com/archive/2025/11/21/tree-me/), + mentioned in [Git Rev News Edition #129](https://git.github.io/rev_news/2025/11/30/edition-129/). + + [Managing Multiple Claude Code Sessions Without Worktrees](https://blog.gitbutler.com/parallel-claude-code/), + mentioned in [Git Rev News Edition #125](https://git.github.io/rev_news/2025/07/31/edition-125/). + + [How to use git worktree effectively with Python projects](https://www.andreagrandi.it/posts/how-to-use-git-worktree-effectively-with-python-projects/), + mentioned in [Git Rev News Edition #125](https://git.github.io/rev_news/2025/07/31/edition-125/). ++ [Using Git with coding agents](https://simonwillison.net/guides/agentic-engineering-patterns/using-git-with-coding-agents/) + is a chapter from the guide [Agentic Engineering Patterns](https://simonwillison.net/guides/agentic-engineering-patterns/), + available on Simon Willison’s Weblog. ++ [How I organize git repos locally](https://blog.esc.sh/how-i-organize-git-repos-locally/) + by Mansoor Majeed on their Esc\.sh blog. ++ [SSH certificates and git signing](https://codon.org.uk/~mjg59/blog/p/ssh-certificates-and-git-signing/) + on Matthew Garrett's Blog. + + [Signing Git Commits with SSH Keys](https://blog.dbrgn.ch/2021/11/16/git-ssh-signatures/) + was first mentioned in [Git Rev News Edition #83](https://git.github.io/rev_news/2022/01/31/edition-83/). + + See also [Git signatures with SSH certificates](https://mjg59.dreamwidth.org/60916.html) + by Matthew Garret on his old mjg59's journal blog, + mentioned in [Git Rev News Edition #91](https://git.github.io/rev_news/2022/09/30/edition-91/). ++ [Choosing the best git branching strategy for continuous delivery in your team](https://geshan.com.np/blog/2026/03/git-branching-strategy-for-continuous-delivery/) + by Geshan Manandhar on his blog: compares Git-Flow, GitHub Flow, and Trunk-based development, + recommending GitHub Flow. + + See also [Patterns for Managing Source Code Branches](https://martinfowler.com/articles/branching-patterns.html) + by Martin Fowler (author of the [Refactoring: Improving the Design of Existing Code](https://martinfowler.com/books/refactoring.html) book), + which was first mentioned in [Git Rev News Edition #63](https://git.github.io/rev_news/2020/05/28/edition-63/). ++ [Git: Remove Dead Branches](https://nathan-long.com/blog/git-remove-dead-branches/) + by Nathan Long on his blog. + The script described in detail should probably use `git for-each-ref` + rather than parse user-facing `git branch` command, though. ++ [Selectively ignore lines in git diff](https://lornajane.net/posts/2026/selectively-ignore-lines-in-git-diff) + by using `git diff --ignore-matching-lines=` (or `-I` in short). + Article by Lorna Jane Mitchell on her LornaJane blog. ++ [Git: ignoring temporary changes](https://blog.narf.ssji.net/2026/03/18/git-ignoring-temporary-changes/) + by Olivier Mehani on Narf blog. + He proposes using `git update-index --assume-unchanged `, which is not safe; + a safer solition is to use `--skip-worktree` instead (won't lose changes, may prevent safe operation). + + Compare [Use skip-worktree to ignore modified files](https://www.brandonpugh.com/til/git/skip-worktree-ignore-modified-files/) + by Brandon Pugh, mentioned in [Git Rev News Edition #129](https://git.github.io/rev_news/2025/11/30/edition-129/). ++ [SQLite on Git, Prologue: Why do we need random access in git](https://blog.lysk.tech/sqlite-on-git-prologue/) and + [SQLite on Git, Part I: The .git folder - Falling down the Rabbithole](https://blog.lysk.tech/sqlite-on-git-part-1) + are first two parts of upcoming series of blogposts, where the author shares a research + enabling one to have a version controlled filesystem + that allows to run versioned SQLite database on top of Git's internal storage. + Written by Martin R. Lysk on his blog. + + Contrast [Git in Postgres](https://nesbitt.io/2026/02/26/git-in-postgres.html) + by Andrew Nesbitt mentioned in [Git Rev News Edition #132](https://git.github.io/rev_news/2026/02/28/edition-132/). ++ [GotHub all the things](https://x61.sh/log/2026/03/14032026191148-gothub.html) + by 𝚐𝚘𝚗𝚣𝚊𝚕𝚘 on x61\.sh blog. + + The [Game of Trees Hub](https://gothub.org/) (GotHub) + is a transparently funded Git repository hosting service, + with infrastructure on OpenBSD and the [Game of Trees (GoT)](https://gameoftrees.org/) VCS, + mentioned in [Git Rev News Edition #131](https://git.github.io/rev_news/2026/01/31/edition-131/) + and [#132](https://git.github.io/rev_news/2026/02/28/edition-132/). ++ [An easy way to mirror git repositories](https://dyyni.org/posts/easy-way-to-mirror-git-repos/) + with the help of author's little shell script “[ferne](https://codeberg.org/2ug/shellscripts/src/branch/master/ferne)”. ++ [Rebasing in Magit](https://entropicthoughts.com/rebasing-in-magit) + by kqr (Chris) on Entropic Thoughts. + + [Magit](https://magit.vc/) is a popular [Emacs](https://www.gnu.org/software/emacs) editor interface to Git, + first mentioned in [Git Rev News Edition #6](https://git.github.io/rev_news/2015/08/05/edition-6/), + and most recently in [Edition #130](https://git.github.io/rev_news/2025/12/31/edition-130/) + and [#132](https://git.github.io/rev_news/2026/02/28/edition-132/). ++ [Reviewing large changes with Jujutsu](https://ben.gesoff.uk/posts/reviewing-large-changes-with-jj/) + by Ben Gesoff on his blog. + + [Jujutsu (`jj`)](https://jj-vcs.github.io/jj/) is a Git-compatible version control system, + written in Rust, which was first mentioned in [Git Rev News Edition #85](https://git.github.io/rev_news/2022/03/31/edition-85/). ++ [Magit and Majutsu: discoverable version-control](https://lwn.net/Articles/1060024/) + by Daroc Alden on LWN\.net. + + [Majutsu](https://github.com/0WD0/majutsu) provides a [Magit](https://magit.vc/)-style + interface for [Jujutsu (`jj`)](https://www.jj-vcs.dev/) in GNU Emacs, + was first mentioned in [Git Rev News Edition #132](https://git.github.io/rev_news/2026/02/28/edition-132/). ++ [Editing changes in patch format with Jujutsu VCS](https://www.knifepoint.net/~kat/kb-jj-patchedit.html) + by Katalin Rebhan (@dblsaiko) on her blog. ++ [Manyana: A Coherent Vision for the Future of Version Control](https://bramcohen.com/p/manyana) + and [More on Version Control: This may have some legs](https://bramcohen.com/p/more-on-version-control) + by Bram Cohen on Bram's Thoughts, + about his approach of using CRDTs (Conflict-free Replicated Data Types) for version control.
+ The ideas behind [Manyana](https://github.com/bramcohen/manyana), + with a prototype written in Python, looks a bit similar to [Codeville](https://web.archive.org/web/20070202014158/http://codeville.org/), + distributed version control system created around 2005 by Ross and Bram Cohen, + with unique merging algorithm, no longer existing. ++ [Development tools: Sashiko, b4 review, and API specification](https://lwn.net/Articles/1063303/) + by Jonathan Corbet on LWN\.net ([free link](https://lwn.net/SubscriberLink/1063303/c076cd05ab3bef54/)). + + Konstantin Ryabitsev's [b4 tool](https://b4.docs.kernel.org/en/latest/) + was first mentioned in [Git Rev News Edition #61](https://git.github.io/rev_news/2020/03/25/edition-61/), + and most recently in [Edition #127](https://git.github.io/rev_news/2025/09/30/edition-127/). + It is also listed on [Hacking Git](https://git.github.io/Hacking-Git/) page. ++ [Mercurial at Google: Also known as Fig](https://mercurial.paris/download/Mercurial%20at%20Google.pdf), + slides by Martin von Zweigbergk, presented at 2023-04-06. + Automate Your Code with GitHub Actions ([Part 1](https://www.git-tower.com/blog/github-actions-fundamentals) and [Part 2](https://www.git-tower.com/blog/github-actions-events-and-triggers)) by Bas Steins on Tower's Blog. @@ -484,7 +662,125 @@ __Light reading__ __Easy watching__ --> +__Scientific papers__ ++ Benedikt Schesch, Ryan Featherman, Kenneth J Yang, Ben Roberts, and Michael D. Ernst: + _"[Evaluation of Version Control Merge Tools.](https://homes.cs.washington.edu/~mernst/pubs/merge-evaluation-ase2024.pdf)"_ + at 39th IEEE/ACM International Conference on Automated Software Engineering (ASE '24). + Association for Computing Machinery, New York, NY, USA, 831–83. + + + Authors evaluated (using Java projects from + [GitHub’s Greatest Hits](https://archiveprogram.github.com/greatest-hits/) + and [RepoReapers / Reaper](https://reporeapers.github.io/) datasets) + the following CLI tools: + [different variants of `git merge`](https://git-scm.com/docs/git-merge#_merge_strategies) algorithm, + [git-hires-merge](https://github.com/paulaltin/git-hires-merge), + [IntelliMerge](https://github.com/Symbolk/IntelliMerge) (Java only), + [Spork](https://github.com/ASSERT-KTH/spork) (Java only), + and their [Plume-lib merging](https://github.com/plume-lib/merging). + + They considered, but did not evaluate + [JDime](https://github.com/se-sic/jdime) (Java only) because of its limitations; + and AutoMerge (also known as AutoMerge-PTM), DeepMerge, MergeBERT - + because those tools are not publicly available. + They could not evaluate tools that base on GUI interaction, + like [RefMerge](https://github.com/ualberta-smr/RefMerge) (IntelliJ IDEA plugin) + or [FSTMerge](http://www.fosd.de/SSMerge/) (part of FeatureHouse, depends on KDiff3). + + [Mergiraf](https://mergiraf.org/) did not exists at the time this paper was written. + Mergiraf was mentioned in [Git Rev News Edition #117](https://git.github.io/rev_news/2024/11/30/edition-117/), + [#119](https://git.github.io/rev_news/2025/01/31/edition-119/) (in passing), + and [#129](https://git.github.io/rev_news/2025/11/30/edition-129/). + + [SemanticMerge](https://www.semanticmerge.com/semanticmerge-intro-guide), + a proprietary tool with 15 or 30 day trial, might have been defunct then (since 2013); + nowadays its homepage page is taken by SEO spam. + It was mentioned in [Git Rev News Edition #38](https://git.github.io/rev_news/2018/04/18/edition-38/). ++ Joao Pedro Duarte, Paulo Borba, and Guilherme Cavalcanti: + _"LastMerge: A language-agnostic structured tool for code integration"_ + preprint on [arXiv:2507.19687](https://arxiv.org/abs/2507.19687) (25 July 2025). + It compares four structured merge tools: + two Java specific tools, JDime and Spork, and their generic counterparts, + respectively Mergiraf and their LastMerge tool (currently not available). + + They also mention [s3m](https://github.com/guilhermejccavalcanti/s3m) + ([Semistructured 3-Way Merge](https://pauloborba.cin.ufpe.br/project/s3m/)) for Java. ++ Qingyu Zhang, Junzhe Li, Jiayi Lin, Jie Ding, Lanteng Lin, and Chenxiong Qian: + _"WizardMerge—Save Us from Merging without Any Clues."_ + ACM Transactions on Software Engineering and Methodology, Volume 35, Issue 1; + Article No.: 22 (11 December 2025), 28 pages. + + + An open-source code-merging auxiliary prototype named + [WizardMerge](https://github.com/HKU-System-Security-Lab/WizardMerge), + together with evaluation datasets, is available on GitHub. + Written in C++. + __Git tools and sites__ ++ [A Partial Extract of revctrl.org](https://tonyg.github.io/revctrl.org/index.html), + a Revision Control wiki, which has fallen victim to spam, and is now taken over. + Scraped, archived, and edited by Tony Garnock-Jones; + spam cleanup and improvements to formatting by Michael Haggerty. + Unfortunately, all the edit history of the wiki was lost, + and individual pages do not have clear authorship. ++ [Version Control with Git for Data Science](https://guides.nyu.edu/datascience/vcs), + a part of Research Guides for data science community at New York University.
+ References [Software Carpentry "Version Control with Git"](https://swcarpentry.github.io/git-novice/), + mentioned in [Git Rev News Edition #86](https://git.github.io/rev_news/2022/04/30/edition-86/). ++ [git bayesect](https://github.com/hauntsaninja/git_bayesect): Bayesian git bisection. + You can use this tool to detect changes in likelihoods of events, for instance, + to isolate a commit where a slightly flaky test became very flaky. + You don't need to know the likelihoods (although you can provide priors), + just that something has changed at some point in some direction. + If your code has started gaslighting you, give it a try! + Written in Python, under MIT license. ++ [GitStats](https://github.com/em1208/GitStats) is a statistics generator for git repositories. + Currently it produces only HTML output with tables and graphs, + providing total files, lines, commits, authors, commits by hour of day, day of week, etc. + Fork of . + Written in Python, under GPLv2 or older license.
+ Original version demo available at . ++ [GitTop](https://github.com/hjr265/gittop) is terminal UI tool + for visualizing Git repository statistics, inspired by htop/btop. + Written in Go, under BSD-3-Clause license. + + See also [My First Fully Agentic Coding Project: GitTop](https://hjr265.me/blog/building-gittop-with-agentic-coding/) + by Mahmud Ridwan on hjr265\.me. ++ [diffsoup](https://github.com/junglerobba/diffsoup) is a Gerrit-style + TUI patchset diff viewer for pull requests, using Jujutsu. + Written in Rust, under MIT license. ++ [fzf-git.sh](https://github.com/junegunn/fzf-git.sh): + bash, zsh, and fish key bindings for Git objects, + powered by [fzf](https://github.com/junegunn/fzf). + Each binding will allow you to browse through Git objects of a certain type, + and select from TUI the objects you want to paste to your command-line. + Under MIT license. ++ [Git X-Modules](https://gitmodules.com/) is a tool to manage modular Git projects. + Alternative to built-in [`git submodule`](https://git-scm.com/docs/git-submodule) + (see also [Git Tools - Submodules](https://git-scm.com/book/en/v2/Git-Tools-Submodules) + chapter in "Pro Git" 2nd Ed.), [`git subtree`](https://github.com/apenwarr/git-subtree) + (which uses built-in [subtree](https://git-scm.com/docs/git-merge#Documentation/git-merge.txt-subtreepath) merge strategy), + [`git stree`](https://github.com/deliciousinsights/git-stree), + and [`git subrepo`](https://github.com/ingydotnet/git-subrepo). ++ [GitBucket](https://gitbucket.github.io/) is Open Source Git platform on JVM + (software forge), with easy installation, high extensibility & GitHub API compatibility. + Written in Scala, under Apache License Version 2.0. ++ [CodebaseHQ](https://www.codebasehq.com/) by Krystal is a software forge that + offers Git, Mercurial and Subversion hosting, with project management tools. + No free tier, 15 day free trial. ++ [`git-memento`](https://github.com/mandel-macaque/memento) is a Git extension + that records the AI coding session used to produce a commit. + It attaches AI conversation transcripts as [git notes](https://git-scm.com/docs/git-notes), + creating an audit trail for AI-assisted development. + Written in F# and TypeScript, under MIT license. ++ [ChunkHound](https://chunkhound.github.io/) is a local-first codebase intelligence, + which researches your codebase, + extracting architecture, patterns, and institutional knowledge, + to give your AI assistant the context it needs - deep understanding + of your code, files, and architectural decisions. + Integrates via [MCP}(https://spec.modelcontextprotocol.io/) (Model Context Protocol). + Written in Python, under MIT license. ++ [Sashiko](https://sashiko.dev/) is an agentic Linux kernel code review system, + using LLM (Large Language Model). It monitors public mailing lists + to thoroughly evaluate proposed Linux kernel changes. + The system acts like a team of specialized reviewers covering domains + from high-level architecture verification and security audits + to low-level resource management and concurrency analysis. + It is an open-source project that belongs to the Linux Foundation, + licensed under the Apache License, Version 2.0. ## Releases From 0897ab1ffd011de477c8074cb70d776f6bf1a860 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=C5=A0t=C4=9Bp=C3=A1n=20N=C4=9Bmec?= Date: Wed, 1 Apr 2026 11:03:24 +0200 Subject: [PATCH 12/19] rn-133: minor copy edit --- rev_news/drafts/edition-133.md | 38 +++++++++++++++++----------------- 1 file changed, 19 insertions(+), 19 deletions(-) diff --git a/rev_news/drafts/edition-133.md b/rev_news/drafts/edition-133.md index c935ad593..984493088 100644 --- a/rev_news/drafts/edition-133.md +++ b/rev_news/drafts/edition-133.md @@ -494,7 +494,7 @@ __Various__ code collaboration stack built on Git. It was first mentioned in [Git Rev News Edition #49](https://git.github.io/rev_news/2019/03/20/edition-49/) and most recently in [edition #131](https://git.github.io/rev_news/2026/01/31/edition-131/).
- Compare [Tangled](https://tangled.org/) (built on top of AT Protocol), + Compare with [Tangled](https://tangled.org/) (built on top of AT Protocol), [Grasp](https://ngit.dev/grasp/) and [`git str`](https://github.com/fiatjaf/gitstr) (built on top of Nostr), and [`git-ssb`](https://scuttlebot.io/apis/community/git-ssb.html) (built on top of Secure-ScuttleButt (SSB); though SSB ecosystem contracted, with latest news from 2024). + [b4's Review TUI With AI Integration Nearing Pre-Alpha Release](https://www.phoronix.com/news/b4-review-nears-pre-alpha) @@ -526,7 +526,7 @@ __Light reading__ the problem of flaky, non-deterministic tests. + [Git Tricks with Tri and Difft](https://nabeelvalley.co.za/blog/2026/26-03/tri-x-git-tricks/) by Nabeel Valley on their blog. - + [Tri](https://github.com/sftsrv/tri) is TUI interactive directory tree browser, + + [Tri](https://github.com/sftsrv/tri) is a TUI interactive directory tree browser, and [difft, or Difftastic](https://difftastic.wilfred.me.uk/introduction.html) is a structural diff tool that understands syntax. Difftastic was first mentioned in [Git Rev News Edition #86](https://git.github.io/rev_news/2022/04/30/edition-86/), @@ -552,10 +552,10 @@ __Light reading__ as buildings, grouped together in districts corresponding to top-level packages (squarified treemap), with footprint corresponding to size in lines of code, height corresponding to complexity, and color corresponding to "health". - Follows from [Legibility: A Scaling Bottleneck of the Agentic Era](https://verial.xyz/essays/legibility) essay. + Follows from the [Legibility: A Scaling Bottleneck of the Agentic Era](https://verial.xyz/essays/legibility) essay. + [“Use git worktrees,” they said. “It’ll be fun!” they said.](https://daveschumaker.net/use-git-worktrees-they-said-itll-be-fun-they-said/) by Dave Schumaker on his blog. - This posts describes problem with often used solutions like + This post describes a problem with often used solutions like symlinked `node_modules` or `.venv` directories, Yarn’s hardlinks-global mode, APFS Copy-on-Write (`cp -c`) - which is also supported by other filesystems. Proposes keeping a fixed pool of 6 worktree slots, and recycling them as needed. @@ -602,14 +602,14 @@ __Light reading__ + [Git: ignoring temporary changes](https://blog.narf.ssji.net/2026/03/18/git-ignoring-temporary-changes/) by Olivier Mehani on Narf blog. He proposes using `git update-index --assume-unchanged `, which is not safe; - a safer solition is to use `--skip-worktree` instead (won't lose changes, may prevent safe operation). + a safer solution is to use `--skip-worktree` instead (won't lose changes, may prevent safe operation). + Compare [Use skip-worktree to ignore modified files](https://www.brandonpugh.com/til/git/skip-worktree-ignore-modified-files/) by Brandon Pugh, mentioned in [Git Rev News Edition #129](https://git.github.io/rev_news/2025/11/30/edition-129/). + [SQLite on Git, Prologue: Why do we need random access in git](https://blog.lysk.tech/sqlite-on-git-prologue/) and [SQLite on Git, Part I: The .git folder - Falling down the Rabbithole](https://blog.lysk.tech/sqlite-on-git-part-1) - are first two parts of upcoming series of blogposts, where the author shares a research + are the first two parts of an upcoming series of blogposts, where the author shares research enabling one to have a version controlled filesystem - that allows to run versioned SQLite database on top of Git's internal storage. + that allows running a versioned SQLite database on top of Git's internal storage. Written by Martin R. Lysk on his blog. + Contrast [Git in Postgres](https://nesbitt.io/2026/02/26/git-in-postgres.html) by Andrew Nesbitt mentioned in [Git Rev News Edition #132](https://git.github.io/rev_news/2026/02/28/edition-132/). @@ -635,8 +635,8 @@ __Light reading__ + [Magit and Majutsu: discoverable version-control](https://lwn.net/Articles/1060024/) by Daroc Alden on LWN\.net. + [Majutsu](https://github.com/0WD0/majutsu) provides a [Magit](https://magit.vc/)-style - interface for [Jujutsu (`jj`)](https://www.jj-vcs.dev/) in GNU Emacs, - was first mentioned in [Git Rev News Edition #132](https://git.github.io/rev_news/2026/02/28/edition-132/). + interface for [Jujutsu (`jj`)](https://www.jj-vcs.dev/) in GNU Emacs. + First mentioned in [Git Rev News Edition #132](https://git.github.io/rev_news/2026/02/28/edition-132/). + [Editing changes in patch format with Jujutsu VCS](https://www.knifepoint.net/~kat/kb-jj-patchedit.html) by Katalin Rebhan (@dblsaiko) on her blog. + [Manyana: A Coherent Vision for the Future of Version Control](https://bramcohen.com/p/manyana) @@ -645,14 +645,14 @@ __Light reading__ about his approach of using CRDTs (Conflict-free Replicated Data Types) for version control.
The ideas behind [Manyana](https://github.com/bramcohen/manyana), with a prototype written in Python, looks a bit similar to [Codeville](https://web.archive.org/web/20070202014158/http://codeville.org/), - distributed version control system created around 2005 by Ross and Bram Cohen, - with unique merging algorithm, no longer existing. + a distributed version control system created around 2005 by Ross and Bram Cohen, + with a unique merging algorithm, no longer existing. + [Development tools: Sashiko, b4 review, and API specification](https://lwn.net/Articles/1063303/) by Jonathan Corbet on LWN\.net ([free link](https://lwn.net/SubscriberLink/1063303/c076cd05ab3bef54/)). + Konstantin Ryabitsev's [b4 tool](https://b4.docs.kernel.org/en/latest/) was first mentioned in [Git Rev News Edition #61](https://git.github.io/rev_news/2020/03/25/edition-61/), and most recently in [Edition #127](https://git.github.io/rev_news/2025/09/30/edition-127/). - It is also listed on [Hacking Git](https://git.github.io/Hacking-Git/) page. + It is also listed on the [Hacking Git](https://git.github.io/Hacking-Git/) page. + [Mercurial at Google: Also known as Fig](https://mercurial.paris/download/Mercurial%20at%20Google.pdf), slides by Martin von Zweigbergk, presented at 2023-04-06. @@ -676,15 +676,15 @@ __Scientific papers__ [git-hires-merge](https://github.com/paulaltin/git-hires-merge), [IntelliMerge](https://github.com/Symbolk/IntelliMerge) (Java only), [Spork](https://github.com/ASSERT-KTH/spork) (Java only), - and their [Plume-lib merging](https://github.com/plume-lib/merging). + and their own [Plume-lib merging](https://github.com/plume-lib/merging). + They considered, but did not evaluate [JDime](https://github.com/se-sic/jdime) (Java only) because of its limitations; and AutoMerge (also known as AutoMerge-PTM), DeepMerge, MergeBERT - because those tools are not publicly available. - They could not evaluate tools that base on GUI interaction, + They could not evaluate tools based on GUI interaction, like [RefMerge](https://github.com/ualberta-smr/RefMerge) (IntelliJ IDEA plugin) or [FSTMerge](http://www.fosd.de/SSMerge/) (part of FeatureHouse, depends on KDiff3). - + [Mergiraf](https://mergiraf.org/) did not exists at the time this paper was written. + + [Mergiraf](https://mergiraf.org/) did not exist at the time this paper was written. Mergiraf was mentioned in [Git Rev News Edition #117](https://git.github.io/rev_news/2024/11/30/edition-117/), [#119](https://git.github.io/rev_news/2025/01/31/edition-119/) (in passing), and [#129](https://git.github.io/rev_news/2025/11/30/edition-129/). @@ -697,7 +697,7 @@ __Scientific papers__ preprint on [arXiv:2507.19687](https://arxiv.org/abs/2507.19687) (25 July 2025). It compares four structured merge tools: two Java specific tools, JDime and Spork, and their generic counterparts, - respectively Mergiraf and their LastMerge tool (currently not available). + Mergiraf and their own LastMerge tool (currently not available), respectively. + They also mention [s3m](https://github.com/guilhermejccavalcanti/s3m) ([Semistructured 3-Way Merge](https://pauloborba.cin.ufpe.br/project/s3m/)) for Java. + Qingyu Zhang, Junzhe Li, Jiayi Lin, Jie Ding, Lanteng Lin, and Chenxiong Qian: @@ -755,8 +755,8 @@ __Git tools and sites__ (which uses built-in [subtree](https://git-scm.com/docs/git-merge#Documentation/git-merge.txt-subtreepath) merge strategy), [`git stree`](https://github.com/deliciousinsights/git-stree), and [`git subrepo`](https://github.com/ingydotnet/git-subrepo). -+ [GitBucket](https://gitbucket.github.io/) is Open Source Git platform on JVM - (software forge), with easy installation, high extensibility & GitHub API compatibility. ++ [GitBucket](https://gitbucket.github.io/) is an Open Source Git platform on JVM + (a software forge), with easy installation, high extensibility & GitHub API compatibility. Written in Scala, under Apache License Version 2.0. + [CodebaseHQ](https://www.codebasehq.com/) by Krystal is a software forge that offers Git, Mercurial and Subversion hosting, with project management tools. @@ -771,7 +771,7 @@ __Git tools and sites__ extracting architecture, patterns, and institutional knowledge, to give your AI assistant the context it needs - deep understanding of your code, files, and architectural decisions. - Integrates via [MCP}(https://spec.modelcontextprotocol.io/) (Model Context Protocol). + Integrates via [MCP](https://spec.modelcontextprotocol.io/) (Model Context Protocol). Written in Python, under MIT license. + [Sashiko](https://sashiko.dev/) is an agentic Linux kernel code review system, using LLM (Large Language Model). It monitors public mailing lists From 557f6c4eb0f87093d78be089f2036aca1bba280d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=C5=A0t=C4=9Bp=C3=A1n=20N=C4=9Bmec?= Date: Wed, 1 Apr 2026 11:05:27 +0200 Subject: [PATCH 13/19] rn-133: drop the git-ssb mention (seems dead) The scuttlebot.io domain has expired (the link lands on registrar's parking page) and the git-ssb GitHub repo[1] only contains a README.md linking to the now expired domain. [1] https://github.com/clehner/git-ssb --- rev_news/drafts/edition-133.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/rev_news/drafts/edition-133.md b/rev_news/drafts/edition-133.md index 984493088..333618a7c 100644 --- a/rev_news/drafts/edition-133.md +++ b/rev_news/drafts/edition-133.md @@ -495,8 +495,7 @@ __Various__ It was first mentioned in [Git Rev News Edition #49](https://git.github.io/rev_news/2019/03/20/edition-49/) and most recently in [edition #131](https://git.github.io/rev_news/2026/01/31/edition-131/).
Compare with [Tangled](https://tangled.org/) (built on top of AT Protocol), - [Grasp](https://ngit.dev/grasp/) and [`git str`](https://github.com/fiatjaf/gitstr) (built on top of Nostr), and - [`git-ssb`](https://scuttlebot.io/apis/community/git-ssb.html) (built on top of Secure-ScuttleButt (SSB); though SSB ecosystem contracted, with latest news from 2024). + [Grasp](https://ngit.dev/grasp/) and [`git str`](https://github.com/fiatjaf/gitstr) (built on top of Nostr). + [b4's Review TUI With AI Integration Nearing Pre-Alpha Release](https://www.phoronix.com/news/b4-review-nears-pre-alpha) by Michael Larabel in Linux Kernel section on Phoronix. From 0c70b1d7b786c2c7a392a6cf4ba84159a784fcf5 Mon Sep 17 00:00:00 2001 From: Markus Jansen Date: Wed, 1 Apr 2026 22:29:29 +0200 Subject: [PATCH 14/19] rn-133: Tiny fix (1/2): indented article. --- rev_news/drafts/edition-133.md | 468 ++++++++++++++++----------------- 1 file changed, 234 insertions(+), 234 deletions(-) diff --git a/rev_news/drafts/edition-133.md b/rev_news/drafts/edition-133.md index 333618a7c..20f2d9990 100644 --- a/rev_news/drafts/edition-133.md +++ b/rev_news/drafts/edition-133.md @@ -29,240 +29,240 @@ This edition covers what happened during the months of February and March 2026. + [git-am applies commit message diffs](https://lore.kernel.org/git/bcqvh7ahjjgzpgxwnr4kh3hfkksfruf54refyry3ha7qk7dldf@fij5calmscvm) -On February 6, 2026, Matthias Beyer forwarded to the Git mailing list a -surprising warning that had just circulated on Mastodon: - -> PSA: Did you know that it's **unsafe** to put code diffs into your -> commit messages? -> -> Such diffs will be applied by patch(1) (also git-am(1)) as part of -> the code change! -> -> This is how a sleep(1) made it into i3 4.25-2 in Debian unstable. - -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 -in the commit message was applied as actual code, sneaking a spurious -`sleep(1)` 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 -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 -the boundary between the two: - -- a line consisting of only three dashes (`---`), -- a line beginning with `diff -`, or -- 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) -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 -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 -expected commit. - -This historical context also explained why git-am(1) 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 -problem (in 2015, 2022, and 2024). The stream is simply ambiguous by -design. Even the `---` marker itself cannot be used to robustly split -things, since `---` on a line by itself is a valid diff hunk line -indicating that the string `--` was removed from a file. - -Matthias proposed parsing from the end of the email rather than from -the top. Peff replied that this would still be ambiguous for the same -reasons, and would introduce new corner cases. - -Jacob Keller noted early on that the issue was certainly surprising but -that he was unsure it constituted a security attack vector, since -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 -commit message. - -Florian Weimer wondered whether the git-format-patch(1) 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 -require indented diffs, it would only partially mitigate the problem, -because patch(1) (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). - -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 -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` -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 -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 -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) -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) -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 `---`, -it would not be inserted into the commit message when applied. - -Peff replied that this was trickier than it sounded: the new marker -would have to be something that could never appear legitimately in a -commit message, and both sides would need to complain if they saw -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 -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. - -Peff also proposed a simpler receiver-side improvement: a -`git am --strict` mode that would always require a `---` separator -before the diff, on the assumption that well-formatted patches from Git -always have one. This would not help with diffs that legitimately -appear before the `---`, but would eliminate the most common accidental -cases. - -None of these ideas led to an immediate implementation, as they all -involve backward compatibility tradeoffs that would need careful -thought. - -On February 8, Kristoffer sent a documentation patch titled "doc: add -caveat about roundtripping format-patch" which introduced a new -`Documentation/format-patch-caveats.adoc` file explaining the -behavior. The caveat was designed to be included in the documentation -for git-am(1), git-format-patch(1), and git-send-email(1). - -Junio reviewed -[version 1](https://lore.kernel.org/git/format-patch_caveats.281@msgid.xyz) -and offered a correction to the wording: rather than saying that an -unindented diff in the commit message "will not only cut the message -short but cause that very diff to be applied, along with the patch in -the patch section," Junio noted that the outcome is not so -deterministic. The diff in the commit message might get applied, or -the patch machinery might trip on something and fail outright. He also -flagged that the space after the `---` in the cover letter was -inconsistent with the project's conventions. - -Phillip Wood reviewed the patch and found the mention of -git-send-email(1) a bit distracting, since that command merely runs -git-format-patch(1) and does not do any formatting itself. He also -suggested wording improvements: replacing "One might want to use [...] -patch(1)" with "Given these limitations, one might be tempted to [...]". - -Kristoffer incorporated all of this in -[version 2](https://lore.kernel.org/git/V2_format-patch_caveats.34b@msgid.xyz), -which dropped the git-send-email(1) mention from the introductory -paragraph (while keeping the CAVEATS section in its documentation, for -users who encounter it there), removed example code blocks in favor of -clearer prose, and used the list of message-terminating patterns -already present in git-am(1)'s documentation. Junio reviewed it and -queued it with the comment "Nicely written." - -A third version, -[version 3](https://lore.kernel.org/git/V3_format-patch_caveats.354@msgid.xyz), -was submitted and received Junio's approval to go to `next`. - -Meanwhile, Phillip had observed that since the parsing cannot be fixed, -"perhaps we should update our sample `commit-msg` hook to reject -messages that will cause problems." On February 7, he sent a 3-patch -series titled "commit-msg.sample: reject messages that would confuse -`git am`". The series: - -1. Added a `.gitattributes` rule for sample hooks (which are shell - scripts but have `.sample` extensions). -2. Extended the sample `commit-msg` hook to scan the body of the commit - 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 - message. - -Peff reacted with measured skepticism to patch 3 in -[version 1](https://lore.kernel.org/git/cover.1770476279.git.phillip.wood@dunelm.org.uk): -he and Junio both pointed out that they themselves sometimes use `---` -intentionally in commit messages to add notes that will appear in the -formatted patch email but not end up in the final commit message when -applied. Junio explained the trick: "when I know what I want to write -below the three-dash lines, I would commit with `---` and additional -notes below it, so that I do not forget during format-patch. When the -commit is turned into a patch email [...] `am` cuts at the first one, -and `apply` knows that the garbage lines at front, including -three-dash lines, do not matter until it sees `^diff`, this works out -perfectly well." - -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 -[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 -header and so does not go through the patch boundary detection), skips -lines below a scissors line, and handles the `core.commentChar` and -`core.commentString` configuration options for determining which lines -are comments. Junio reviewed version 2 with detailed questions about -the scissors-line logic. - -Kristoffer verified that version 2 worked with `git commit ---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 -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 -git-send-email(1) spelling out exactly how commit messages can -inadvertently interfere with patch application, and an enhanced sample -`commit-msg` hook that rejects messages containing unindented diffs. - -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 -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). + On February 6, 2026, Matthias Beyer forwarded to the Git mailing list a + surprising warning that had just circulated on Mastodon: + + > PSA: Did you know that it's **unsafe** to put code diffs into your + > commit messages? + > + > Such diffs will be applied by patch(1) (also git-am(1)) as part of + > the code change! + > + > This is how a sleep(1) made it into i3 4.25-2 in Debian unstable. + + 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 + in the commit message was applied as actual code, sneaking a spurious + `sleep(1)` 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 + 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 + the boundary between the two: + + - a line consisting of only three dashes (`---`), + - a line beginning with `diff -`, or + - 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) + 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 + 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 + expected commit. + + This historical context also explained why git-am(1) 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 + problem (in 2015, 2022, and 2024). The stream is simply ambiguous by + design. Even the `---` marker itself cannot be used to robustly split + things, since `---` on a line by itself is a valid diff hunk line + indicating that the string `--` was removed from a file. + + Matthias proposed parsing from the end of the email rather than from + the top. Peff replied that this would still be ambiguous for the same + reasons, and would introduce new corner cases. + + Jacob Keller noted early on that the issue was certainly surprising but + that he was unsure it constituted a security attack vector, since + 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 + commit message. + + Florian Weimer wondered whether the git-format-patch(1) 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 + require indented diffs, it would only partially mitigate the problem, + because patch(1) (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). + + 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 + 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` + 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 + 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 + 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) + 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) + 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 `---`, + it would not be inserted into the commit message when applied. + + Peff replied that this was trickier than it sounded: the new marker + would have to be something that could never appear legitimately in a + commit message, and both sides would need to complain if they saw + 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 + 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. + + Peff also proposed a simpler receiver-side improvement: a + `git am --strict` mode that would always require a `---` separator + before the diff, on the assumption that well-formatted patches from Git + always have one. This would not help with diffs that legitimately + appear before the `---`, but would eliminate the most common accidental + cases. + + None of these ideas led to an immediate implementation, as they all + involve backward compatibility tradeoffs that would need careful + thought. + + On February 8, Kristoffer sent a documentation patch titled "doc: add + caveat about roundtripping format-patch" which introduced a new + `Documentation/format-patch-caveats.adoc` file explaining the + behavior. The caveat was designed to be included in the documentation + for git-am(1), git-format-patch(1), and git-send-email(1). + + Junio reviewed + [version 1](https://lore.kernel.org/git/format-patch_caveats.281@msgid.xyz) + and offered a correction to the wording: rather than saying that an + unindented diff in the commit message "will not only cut the message + short but cause that very diff to be applied, along with the patch in + the patch section," Junio noted that the outcome is not so + deterministic. The diff in the commit message might get applied, or + the patch machinery might trip on something and fail outright. He also + flagged that the space after the `---` in the cover letter was + inconsistent with the project's conventions. + + Phillip Wood reviewed the patch and found the mention of + git-send-email(1) a bit distracting, since that command merely runs + git-format-patch(1) and does not do any formatting itself. He also + suggested wording improvements: replacing "One might want to use [...] + patch(1)" with "Given these limitations, one might be tempted to [...]". + + Kristoffer incorporated all of this in + [version 2](https://lore.kernel.org/git/V2_format-patch_caveats.34b@msgid.xyz), + which dropped the git-send-email(1) mention from the introductory + paragraph (while keeping the CAVEATS section in its documentation, for + users who encounter it there), removed example code blocks in favor of + clearer prose, and used the list of message-terminating patterns + already present in git-am(1)'s documentation. Junio reviewed it and + queued it with the comment "Nicely written." + + A third version, + [version 3](https://lore.kernel.org/git/V3_format-patch_caveats.354@msgid.xyz), + was submitted and received Junio's approval to go to `next`. + + Meanwhile, Phillip had observed that since the parsing cannot be fixed, + "perhaps we should update our sample `commit-msg` hook to reject + messages that will cause problems." On February 7, he sent a 3-patch + series titled "commit-msg.sample: reject messages that would confuse + `git am`". The series: + + 1. Added a `.gitattributes` rule for sample hooks (which are shell + scripts but have `.sample` extensions). + 2. Extended the sample `commit-msg` hook to scan the body of the commit + 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 + message. + + Peff reacted with measured skepticism to patch 3 in + [version 1](https://lore.kernel.org/git/cover.1770476279.git.phillip.wood@dunelm.org.uk): + he and Junio both pointed out that they themselves sometimes use `---` + intentionally in commit messages to add notes that will appear in the + formatted patch email but not end up in the final commit message when + applied. Junio explained the trick: "when I know what I want to write + below the three-dash lines, I would commit with `---` and additional + notes below it, so that I do not forget during format-patch. When the + commit is turned into a patch email [...] `am` cuts at the first one, + and `apply` knows that the garbage lines at front, including + three-dash lines, do not matter until it sees `^diff`, this works out + perfectly well." + + 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 + [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 + header and so does not go through the patch boundary detection), skips + lines below a scissors line, and handles the `core.commentChar` and + `core.commentString` configuration options for determining which lines + are comments. Junio reviewed version 2 with detailed questions about + the scissors-line logic. + + Kristoffer verified that version 2 worked with `git commit + --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 + 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 + git-send-email(1) spelling out exactly how commit messages can + inadvertently interfere with patch application, and an enhanced sample + `commit-msg` hook that rejects messages containing unindented diffs. + + 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 + 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). ## Developer Spotlight: Olamide Caleb Bello From 28efa86c212e9709dc1c28275b205f3939201af9 Mon Sep 17 00:00:00 2001 From: Markus Jansen Date: Wed, 1 Apr 2026 23:02:19 +0200 Subject: [PATCH 15/19] rn-133: tiny fixes (2/3) covering the article and spotlight. --- rev_news/drafts/edition-133.md | 54 +++++++++++++++++----------------- 1 file changed, 27 insertions(+), 27 deletions(-) diff --git a/rev_news/drafts/edition-133.md b/rev_news/drafts/edition-133.md index 20f2d9990..bf78aa520 100644 --- a/rev_news/drafts/edition-133.md +++ b/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,22 +93,22 @@ 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. @@ -116,31 +116,31 @@ This edition covers what happened during the months of February and March 2026. 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. From bb80d12bc096c7f2b649e0d411bd81039d6c92eb Mon Sep 17 00:00:00 2001 From: Markus Jansen Date: Wed, 1 Apr 2026 23:48:19 +0200 Subject: [PATCH 16/19] rn-133: Tiny fixes (3/3). Please scrutinize as usual. --- rev_news/drafts/edition-133.md | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/rev_news/drafts/edition-133.md b/rev_news/drafts/edition-133.md index bf78aa520..3e820ee5c 100644 --- a/rev_news/drafts/edition-133.md +++ b/rev_news/drafts/edition-133.md @@ -169,7 +169,7 @@ This edition covers what happened during the months of February and March 2026. thought. On February 8, Kristoffer sent a documentation patch titled "doc: add - caveat about roundtripping format-patch" which introduced a new + caveat about round-tripping format-patch" which introduced a new `Documentation/format-patch-caveats.adoc` file explaining the behavior. The caveat was designed to be included in the documentation for git-am(1), git-format-patch(1), and git-send-email(1). @@ -480,13 +480,13 @@ __Various__ announced that [Fedora Forge](https://forge.fedoraproject.org/explore/organizations), powered by [Forgejo](https://forgejo.org/), is ready for use. If you own a project at [pagure.io](https://pagure.io/), - you must migrate out of it before June 2026; + you must migrate out of it before June 2026; the [How to Migrate Repository from Pagure](https://docs.fedoraproject.org/en-US/forge-documentation/migration/pagure_repository/) guide is there to help with this task. Note that Fedora Forge is narrower in scope than pagure\.io; it is provisioned to host the code, documentation, and tooling that directly build, manage, and govern the Fedora Project. - Personal projects and general upstream development does not belong on Fedora Forge. + Personal projects and general upstream development do not belong on Fedora Forge. + [GNOME GitLab Redirecting Some Git Traffic To GitHub For Reducing Costs](https://www.phoronix.com/news/GNOME-GitHub-GitLab-Redirect) by Michael Larabel in GNOME on Phoronix. + [Radicle: Disclosure of Replay Attack Vulnerability in Signed References](https://radicle.xyz/2026/03/30/disclosure-of-vulnerability-in-signed-references) @@ -497,7 +497,7 @@ __Various__ Compare with [Tangled](https://tangled.org/) (built on top of AT Protocol), [Grasp](https://ngit.dev/grasp/) and [`git str`](https://github.com/fiatjaf/gitstr) (built on top of Nostr). + [b4's Review TUI With AI Integration Nearing Pre-Alpha Release](https://www.phoronix.com/news/b4-review-nears-pre-alpha) - by Michael Larabel in Linux Kernel section on Phoronix. + by Michael Larabel in the Linux Kernel section on Phoronix. __Light reading__ + [The Comforting Lie Of SHA Pinning](https://www.vaines.org/posts/2026-03-24-the-comforting-lie-of-sha-pinning/) @@ -594,7 +594,7 @@ __Light reading__ + [Git: Remove Dead Branches](https://nathan-long.com/blog/git-remove-dead-branches/) by Nathan Long on his blog. The script described in detail should probably use `git for-each-ref` - rather than parse user-facing `git branch` command, though. + rather than parse the user-facing `git branch` command, though. + [Selectively ignore lines in git diff](https://lornajane.net/posts/2026/selectively-ignore-lines-in-git-diff) by using `git diff --ignore-matching-lines=` (or `-I` in short). Article by Lorna Jane Mitchell on her LornaJane blog. @@ -671,14 +671,14 @@ __Scientific papers__ [GitHub’s Greatest Hits](https://archiveprogram.github.com/greatest-hits/) and [RepoReapers / Reaper](https://reporeapers.github.io/) datasets) the following CLI tools: - [different variants of `git merge`](https://git-scm.com/docs/git-merge#_merge_strategies) algorithm, + [different variants of the `git merge`](https://git-scm.com/docs/git-merge#_merge_strategies) algorithm, [git-hires-merge](https://github.com/paulaltin/git-hires-merge), [IntelliMerge](https://github.com/Symbolk/IntelliMerge) (Java only), [Spork](https://github.com/ASSERT-KTH/spork) (Java only), and their own [Plume-lib merging](https://github.com/plume-lib/merging). + They considered, but did not evaluate - [JDime](https://github.com/se-sic/jdime) (Java only) because of its limitations; - and AutoMerge (also known as AutoMerge-PTM), DeepMerge, MergeBERT - + [JDime](https://github.com/se-sic/jdime) (Java only) because of its limitations, + as well as AutoMerge (also known as AutoMerge-PTM), DeepMerge, and MergeBERT because those tools are not publicly available. They could not evaluate tools based on GUI interaction, like [RefMerge](https://github.com/ualberta-smr/RefMerge) (IntelliJ IDEA plugin) @@ -688,7 +688,7 @@ __Scientific papers__ [#119](https://git.github.io/rev_news/2025/01/31/edition-119/) (in passing), and [#129](https://git.github.io/rev_news/2025/11/30/edition-129/). + [SemanticMerge](https://www.semanticmerge.com/semanticmerge-intro-guide), - a proprietary tool with 15 or 30 day trial, might have been defunct then (since 2013); + a proprietary tool with a 15 or 30 day trial, might have been defunct then (since 2013); nowadays its homepage page is taken by SEO spam. It was mentioned in [Git Rev News Edition #38](https://git.github.io/rev_news/2018/04/18/edition-38/). + Joao Pedro Duarte, Paulo Borba, and Guilherme Cavalcanti: @@ -717,7 +717,7 @@ __Git tools and sites__ Unfortunately, all the edit history of the wiki was lost, and individual pages do not have clear authorship. + [Version Control with Git for Data Science](https://guides.nyu.edu/datascience/vcs), - a part of Research Guides for data science community at New York University.
+ a part of Research Guides for the data science community at New York University.
References [Software Carpentry "Version Control with Git"](https://swcarpentry.github.io/git-novice/), mentioned in [Git Rev News Edition #86](https://git.github.io/rev_news/2022/04/30/edition-86/). + [git bayesect](https://github.com/hauntsaninja/git_bayesect): Bayesian git bisection. @@ -727,7 +727,7 @@ __Git tools and sites__ just that something has changed at some point in some direction. If your code has started gaslighting you, give it a try! Written in Python, under MIT license. -+ [GitStats](https://github.com/em1208/GitStats) is a statistics generator for git repositories. ++ [GitStats](https://github.com/em1208/GitStats) is a statistics generator for Git repositories. Currently it produces only HTML output with tables and graphs, providing total files, lines, commits, authors, commits by hour of day, day of week, etc. Fork of . @@ -748,10 +748,10 @@ __Git tools and sites__ and select from TUI the objects you want to paste to your command-line. Under MIT license. + [Git X-Modules](https://gitmodules.com/) is a tool to manage modular Git projects. - Alternative to built-in [`git submodule`](https://git-scm.com/docs/git-submodule) + Alternative to the built-in [`git submodule`](https://git-scm.com/docs/git-submodule) (see also [Git Tools - Submodules](https://git-scm.com/book/en/v2/Git-Tools-Submodules) chapter in "Pro Git" 2nd Ed.), [`git subtree`](https://github.com/apenwarr/git-subtree) - (which uses built-in [subtree](https://git-scm.com/docs/git-merge#Documentation/git-merge.txt-subtreepath) merge strategy), + (which uses the built-in [subtree](https://git-scm.com/docs/git-merge#Documentation/git-merge.txt-subtreepath) merge strategy), [`git stree`](https://github.com/deliciousinsights/git-stree), and [`git subrepo`](https://github.com/ingydotnet/git-subrepo). + [GitBucket](https://gitbucket.github.io/) is an Open Source Git platform on JVM @@ -773,7 +773,7 @@ __Git tools and sites__ Integrates via [MCP](https://spec.modelcontextprotocol.io/) (Model Context Protocol). Written in Python, under MIT license. + [Sashiko](https://sashiko.dev/) is an agentic Linux kernel code review system, - using LLM (Large Language Model). It monitors public mailing lists + using a LLM (Large Language Model). It monitors public mailing lists to thoroughly evaluate proposed Linux kernel changes. The system acts like a team of specialized reviewers covering domains from high-level architecture verification and security audits From e4d65588a72ce96bee8b0c120216094160c79911 Mon Sep 17 00:00:00 2001 From: Christian Couder Date: Thu, 2 Apr 2026 00:31:31 +0200 Subject: [PATCH 17/19] =?UTF-8?q?rn-133:=20add=20=C5=A0t=C4=9Bp=C3=A1n=20N?= =?UTF-8?q?=C4=9Bmec=20among=20the=20helpers?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- rev_news/drafts/edition-133.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/rev_news/drafts/edition-133.md b/rev_news/drafts/edition-133.md index 3e820ee5c..dd89ecff3 100644 --- a/rev_news/drafts/edition-133.md +++ b/rev_news/drafts/edition-133.md @@ -823,5 +823,5 @@ Christian Couder <>, Jakub Narębski <>, Markus Jansen <> and Kaartic Sivaraam <> -with help from Olamide Caleb Bello, Bruno Brito and -Kristoffer Haugsbakk. +with help from Olamide Caleb Bello, Bruno Brito, +Štěpán Němec and Kristoffer Haugsbakk. From 5bca85ae123540563aa99ed913c62a86337cb9d7 Mon Sep 17 00:00:00 2001 From: Christian Couder Date: Thu, 2 Apr 2026 00:33:06 +0200 Subject: [PATCH 18/19] Publish rn-133 in _posts/ --- .../edition-133.md => _posts/2026-03-31-edition-133.markdown | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename rev_news/drafts/edition-133.md => _posts/2026-03-31-edition-133.markdown (100%) diff --git a/rev_news/drafts/edition-133.md b/_posts/2026-03-31-edition-133.markdown similarity index 100% rename from rev_news/drafts/edition-133.md rename to _posts/2026-03-31-edition-133.markdown From c5a72e1f28fcba519f5955db21a574411cb31154 Mon Sep 17 00:00:00 2001 From: Christian Couder Date: Thu, 2 Apr 2026 00:33:06 +0200 Subject: [PATCH 19/19] Add draft for rn-134 --- rev_news/drafts/edition-134.md | 60 ++++++++++++++++++++++++++++++++++ 1 file changed, 60 insertions(+) create mode 100644 rev_news/drafts/edition-134.md diff --git a/rev_news/drafts/edition-134.md b/rev_news/drafts/edition-134.md new file mode 100644 index 000000000..0d238ad44 --- /dev/null +++ b/rev_news/drafts/edition-134.md @@ -0,0 +1,60 @@ +--- +title: Git Rev News Edition 134 (April 30th, 2026) +layout: default +date: 2026-04-30 12:06:51 +0100 +author: chriscool +categories: [news] +navbar: false +--- + +## Git Rev News: Edition 134 (April 30th, 2026) + +Welcome to the 134th edition of [Git Rev News](https://git.github.io/rev_news/rev_news/), +a digest of all things Git. For our goals, the archives, the way we work, and how to contribute or to +subscribe, see [the Git Rev News page](https://git.github.io/rev_news/rev_news/) on [git.github.io](https://git.github.io). + +This edition covers what happened during the months of March and April 2026. + +## Discussions + + + + + + + + + +## Other News + +__Various__ + + +__Light reading__ + + + +__Git tools and sites__ + + +## Releases + + +## Credits + +This edition of Git Rev News was curated by +Christian Couder <>, +Jakub Narębski <>, +Markus Jansen <> and +Kaartic Sivaraam <> +with help from XXX.