diff --git a/GSoC-Participants.md b/GSoC-Participants.md
index df82c0b85..d9a68bf75 100644
--- a/GSoC-Participants.md
+++ b/GSoC-Participants.md
@@ -8,6 +8,17 @@ to Git via GSoC.
+### 2025
+
+1. Ayush Chandekar [ [project](https://summerofcode.withgoogle.com/programs/2025/projects/no7dVMeG) ] [ [final report](https://ayu-ch.github.io/2025/08/29/gsoc-final-report.html) ] [ [blog](https://ayu-ch.github.io/) ]
+2. Lucas Seiki Oshiro [ [project](https://summerofcode.withgoogle.com/programs/2025/projects/fGgMYHwl) ] [ [final report](https://lucasoshiro.github.io/gsoc-en/#final-report) ] [ [blog](https://lucasoshiro.github.io/gsoc-en/#weeks) ]
+3. Meet Soni [ [project](https://summerofcode.withgoogle.com/programs/2025/projects/xVrT5e2q) ] [ [final report](https://inosmeet.github.io/posts/gsoc25/gsoc25_final/) ] [ [blog](https://inosmeet.github.io/posts/gsoc25/) ]
+
+#### References
+
+- [GSoC archive](https://summerofcode.withgoogle.com/programs/2025/organizations/git)
+- [Rev News article](https://git.github.io/rev_news/2025/05/31/edition-123/)
+
### 2024
1. Jialuo She [ [project](https://summerofcode.withgoogle.com/archive/2024/projects/ukm4PTEF) ] [ [final report](https://luolibrary.com/2024/08/25/GSoC-Final-Report/) ] [ [blog](https://luolibrary.com/) ]
diff --git a/Hacking-Git.md b/Hacking-Git.md
index 477c3252a..7dd16d665 100644
--- a/Hacking-Git.md
+++ b/Hacking-Git.md
@@ -3,12 +3,15 @@ layout: default
title: Hacking Git
---
-The goal of this document is not to be a tutorial, but rather to
-point to interesting material that has already been written.
-
-The goal is also not to list all the articles about Git or its
-internals. There are a lot of good resources, including free
-[books](http://git-scm.com/book/en/v2/), about that elsewhere.
+The goal of this document is not to be a tutorial, but rather to point
+to interesting material that has already been written.
+
+The goal is also not to list all the articles, tools or resources
+about Git or its internals. There are a lot of good resources,
+including [free books](http://git-scm.com/book/en/v2/), and the
+[archive of our newsletter](https://git.github.io/rev_news/archive/),
+about that elsewhere. So on this page we focus on what is the most
+interesting for developers starting to work on Git.
Contributions are welcome though! Please contact us on the Git Mailing
list (at [git@vger.kernel.org](mailto:git@vger.kernel.org)) or open an
diff --git a/Outreachy-Participants.md b/Outreachy-Participants.md
new file mode 100644
index 000000000..53c7fed07
--- /dev/null
+++ b/Outreachy-Participants.md
@@ -0,0 +1,60 @@
+---
+layout: default
+title: Outreachy participants
+---
+
+This document collects the list of contributors who've contributed
+to Git via Outreachy.
+
+### Winter 2024-2025
+
+1. Seyi Kuforiji [ [blog](https://seyi-kuforiji-902b48.gitlab.io/) ]
+2. Usman Akinyemi [ [blog](https://uniqueusman.hashnode.dev/tag/outreachy) ]
+
+#### References
+
+- [Rev News - Dec 2024](https://git.github.io/rev_news/2024/12/31/edition-118/)
+
+### Winter 2023-2024
+
+1. Achu Luma [ [blog](https://lumap.gitlab.io/posts/) ]
+
+#### References
+
+- [Rev News - Dec 2023](https://git.github.io/rev_news/2023/11/30/edition-105/)
+
+### Winter 2020-2021
+
+1. Sangeeta [ [blog](https://sangu09.github.io) ]
+2. Joey Salazar [ [blog](https://jsal.home.blog/) ]
+3. Charvi Mendiratta [ [blog](https://charvi-077.github.io/blog/) ]
+
+#### References
+
+- [Rev News - Dec 2020](https://git.github.io/rev_news/2020/12/26/edition-70/)
+
+### Winter 2019-2020
+
+1. Heba W. [ [blog](https://medium.com/@heba.waly) ]
+2. Miriam Rubio [ [blog](https://mirucam.gitlab.io/outreachy_blog/) ]
+
+#### References
+
+- [Rev News - Dec 2019](https://git.github.io/rev_news/2019/12/25/edition-58/)
+
+### Winter 2018-2019
+
+1. Slavica Đukić [ [blog](https://slavicadj.github.io/blog/) ]
+2. Tanushree Tumane [ [blog](https://tanu1596.blogspot.com/) ]
+
+#### References
+
+- [Rev News - Nov 2018](https://git.github.io/rev_news/2018/11/21/edition-45/)
+
+### Winter 2017-2018
+
+1. Olga Telezhnaia [ [blog](https://medium.com/@olyatelezhnaya) ]
+
+#### References
+
+- [Rev News - Nov 2017](https://git.github.io/rev_news/2017/11/22/edition-33/)
diff --git a/_posts/2025-07-31-edition-125.markdown b/_posts/2025-07-31-edition-125.markdown
new file mode 100644
index 000000000..063e936ee
--- /dev/null
+++ b/_posts/2025-07-31-edition-125.markdown
@@ -0,0 +1,645 @@
+---
+title: Git Rev News Edition 125 (July 31st, 2025)
+layout: default
+date: 2025-07-31 12:06:51 +0100
+author: chriscool
+categories: [news]
+navbar: false
+---
+
+## Git Rev News: Edition 125 (July 31st, 2025)
+
+Welcome to the 125th 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](http://git.github.io).
+
+This edition covers what happened during the months of June and July 2025.
+
+## Discussions
+
+
+### General
+
+* 20 years ago: [Meet the new maintainer..](https://lore.kernel.org/git/Pine.LNX.4.58.0507262004320.3227@g5.osdl.org/)
+
+ On July 26 2005, so 20 years ago, Linus Torvalds announced on
+ the mailing list that Junio Hamano accepted the maintainership of
+ the Git project and that Junio "was the obvious choice". Linus said
+ he wasn't dropping Git but he just preferred working on it as a
+ contributor.
+
+ Junio replied with an [A note from the new GIT maintainer](https://lore.kernel.org/git/7vmzo8ss2l.fsf@assigned-by-dhcp.cox.net/)
+ email where he acknowledged his new role as Git maintainer, thanked
+ the community for their support and collaboration, and promised to
+ take a more careful and deliberate approach in shepherding the
+ project. He also said he would post his own patches to the mailing
+ list for review before including them in the repository, and
+ encouraged community feedback.
+
+* [[ANNOUNCE] Git Mini Summit at Open Source Summit Europe, Amsterdam, August 28th](https://lore.kernel.org/git/aGwHt9HCd86hVuKh@pks.im/)
+
+ Patrick Steinhardt announced a Git Mini Summit co-located with the
+ [Open Source Summit Europe](https://events.linuxfoundation.org/open-source-summit-europe/)
+ in Amsterdam on August 28th 2025.
+
+ There will be lightning talks and some time for people to
+ connect. Proposals for the lightning talks should be sent to
+ Patrick, while the possibility to have remote talks is still
+ investigated.
+
+ [Registration is open](https://events.linuxfoundation.org/open-source-summit-europe/features/co-located-events/#git-mini-summit-2025)
+ for both the Git Mini Summit only and for the Open Source Summit Europe including the Git Mini Summit.
+
+
+### Reviews
+
+* [[PATCH v4 0/3] send-email: add oauth2 support and fix outlook breaking threads](https://lore.kernel.org/git/PN3PR01MB9597A83D537E3AE96144227EB8BA2@PN3PR01MB9597.INDPRD01.PROD.OUTLOOK.COM/)
+
+ Last April, Aditya Garg sent a patch series containing three main
+ changes to `git send-email`. He mentioned that he was sending the
+ email series using the very patches he was proposing, via Outlook.
+
+ The first patch was a rebased version of
+ [an earlier patch by Julian Swagemakers](https://lore.kernel.org/git/20250125190131.48717-1-julian@swagemakers.org/)
+ adding support for OAuth2 authentication, which started to be
+ required by Microsoft. Julian's patch unfortunately had been waiting
+ for review for over a year before Aditya picked it up.
+
+ The second patch fixed thread breaking caused by Outlook's
+ proprietary Message-ID handling.
+
+ The final patch added a new option for generating passwords, such as
+ OAuth2 tokens, via an external script.
+
+ Junio Hamano, the Git maintainer, reviewed the three patches saying
+ he liked the commit messages, documentation and code comments even
+ though he suggested a few small style improvements to the code
+ style plus a number of grammar and formatting changes to the
+ documentation.
+
+ He also asked for reviews from others as he said he was not familiar
+ with the `Authen::SASL` library.
+
+ Aditya replied to Junio's review acknowledging the need for more
+ reviews and saying that OAuth2 was a significant and more secure
+ technology. He then took the initiative to Cc Greg Kroah-Hartman,
+ who wrote a precursor of `git send-email` for the Linux kernel.
+
+ M Hickford also replied to Aditya expressing enthusiasm for the work
+ but wondering why the v4 version of the patch series was sent in a
+ new email thread rather than as a reply to the previous version.
+
+ brian m. carlson commented on the second patch saying that replacing
+ message IDs like Outlook does is technically allowed by
+ standards. They raised concerns about hardcoding only two Outlook
+ server hostnames, and suggested adding configuration options for
+ Message-ID generation modes.
+
+ Julian Swagemakers then pointed out that the goal of the third patch
+ could already be achieved using Git's existing custom credential
+ helper mechanism. Aditya confirmed this worked and said he was
+ unaware of this feature, which led to the decision to drop the third
+ patch. Recognizing that the existing feature was poorly
+ discoverable, the discussion led to improvements in Git's
+ documentation, adding clearer examples of using credential helpers
+ for OAuth2 tokens.
+
+ Erik Huelsmann, the maintainer of the `Authen::SASL` Perl module,
+ joined the conversation after Aditya emailed him directly
+ referencing a GitHub issue about the lack of OAuth2 support in
+ `Authen::SASL`. In that issue Erik had
+ [commented that he would be happy to support XOAUTH2](https://github.com/gbarr/perl-authen-sasl/issues/18#issuecomment-2453040190),
+ but needed a patch and a way to test it.
+
+ Aditya and Julian then worked together, with guidance from Erik, to
+ add the necessary XOAUTH2 and OAUTHBEARER support directly into
+ `Authen::SASL`. Shortly after, a new version of the `Authen::SASL`
+ module was officially released with this new functionality. This
+ successful collaboration meant the first patch in the series, which
+ was a workaround for the missing library support, was no longer
+ needed and was subsequently dropped. Instead, the new version of
+ `Authen::SASL` started to benefit all Perl users.
+
+ Greg Kroah-Hartman echoed what brian had suggested about using a
+ configurable solution in the second patch. Greg noted that the
+ initial approach would not cover company-hosted Outlook servers. Yao
+ Zi also contributed to this discussion, noting that Tencent's mail
+ service had similar issues, further reinforcing the need for a
+ flexible solution beyond just hardcoding specific server names.
+
+ That suggestion was then refined by Junio Hamano, who proposed a
+ concrete implementation for the new option by providing an example
+ patch. The final `--[no-]outlook-id-fix` option auto-detects known
+ Outlook servers but allows manual override for other deployments.
+
+ After several iterations on its name and behavior, with Eric
+ Sunshine helping refine the user-facing documentation, Aditya
+ submitted a final, simplified patch series (v6). It now contained
+ only the single, refined patch to fix Outlook thread breaking, with
+ the other two patches having been made obsolete by the
+ `Authen::SASL` library update and the use of existing Git features.
+
+ Aditya's patch was merged and released as part of Git v2.50.0.
+
+
+
+## Developer Spotlight: Usman Akinyemi
+
+_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 Usman Akinyemi, a final-year CS and AI student, and an open-source
+ contributor passionate about Linux, distributed systems, and developer
+ tools. I’ve contributed to core projects like Git, systemd, LLVM, and
+ LibreOffice. During [my Outreachy internship](https://uniqueusman.hashnode.dev/my-outreachy-internship-experience-at-git),
+ I improved Git’s v2 protocol by adding OS-level metadata for better
+ diagnostics and security.
+
+ Currently, I’m a [Google Summer of Code contributor](https://summerofcode.withgoogle.com/programs/2025/projects/wBCitF8F)
+ building a containerized pipeline for medical imaging using Kaapana,
+ Kubernetes and Airflow. I am also currently working on creating a
+ new subtype for RISC-V assembly instructions through the
+ Linux Foundation’s LFX program.
+
+ Outside code, I mentor new contributors, volunteer with DesignIT and
+ LEAD and CODE to teach digital skills, and organize a tech webinar for
+ Nigerian students. I’ll be [speaking at Git Merge 2025](https://git-merge.com/#usman-akinyemi),
+ sharing insights from my open-source journey. I believe in the power of
+ community, collaboration, and curiosity to build a career that crosses
+ borders.
+
+* **How did you initially become interested in contributing to Git,
+ and what motivated you to choose it as your Outreachy project?**
+
+ Though I have been contributing to other projects before applying for
+ Outreachy (Dec 2024), I was just a user of the Git project. When it
+ comes to the Outreachy contribution period when I had to pick a
+ project, I picked both Git and LibreOffice. I picked Git as it is a
+ project I use every time, also the thought of contributing to a
+ project used by almost all the developers in the whole world was
+ definitely a dream coming true. To also maximize my getting selected
+ for Outreachy, I picked Git because it is written in C,
+ which many other participants are always scared to pick (going for the
+ hard thing). The story did not end there as I got selected for both
+ LibreOffice and Git and I had to choose one as my Outreachy projects.
+ It was a hard decision but I picked it mainly because the Git
+ community is a community where it is so easy to communicate with other
+ team members, and it is a community where I clearly know who is who and
+ what they do in the community. Also Git is more well recognised.
+
+* **How do you feel your contribution has impacted the Git community
+ or the broader open source ecosystem?**
+
+ [My contribution](https://lore.kernel.org/git/20250215155130.1756934-1-usmanakinyemi202@gmail.com/)
+ makes a fundamental improvement to the Git v2 protocol by enabling
+ Git clients to share their operating system information via the user
+ agent string. This helps platforms like GitHub, GitLab, and others
+ gain visibility into which OS environments are interacting
+ with their servers. It significantly improves debugging, security
+ auditing, and telemetry, helping maintainers understand usage patterns
+ and tailor support or upgrade strategies accordingly. Since this
+ change is part of the core Git client, it means it is used by all Git
+ users. I’m proud to have contributed something with such
+ wide-reaching, foundational impact.
+
+* **Is there any aspect of Git that you now see differently after
+ having contributed to it?**
+
+ Before contributing to Git, I saw it as a complex tool that "just
+ works". Although I knew Git was different from GitHub, I struggled to
+ clearly differentiate between the two. But after contributing, I could
+ clearly differentiate between the two and I now see Git as a carefully
+ designed software project with a strong emphasis on performance,
+ cross-platform compatibility, and community-driven development.
+
+ I’ve come to appreciate the level of thought and care that goes into
+ every change, from writing clean patches and commit messages to
+ engaging in technical discussions and defending your design decisions.
+
+ Contributing to Git isn’t also about hierarchical review; instead,
+ it’s a collaborative process where every contributor is expected to
+ take full ownership of their patches, understand the problem they are
+ trying to fix, the solution and explain their rationale clearly by
+ writing clean patches, commit messages and engaging in technical
+ discussions and defending your design decisions. In fact, there have
+ been moments when some of my contributions led to insights even long
+ time contributors hadn’t considered, including Junio Hamano. That
+ boosted my confidence not just in contributing to Git, but to other
+ software projects as well, i.e., I can get my patches accepted anywhere,
+ I just need to convince others that it actually solves a problem.
+
+* **How do you balance your contributions with other responsibilities
+ like work or school?**
+
+ Seriously, it has not been easy, most of my contributions to all
+ open source projects have always been during college. But, I have sort
+ of made contributions to open source as one important aspect of my
+ life and also as a way to learn new technologies and also practice
+ whatever new skills I learnt. Contributing to projects millions of
+ people use is also definitely rewarding and satisfying.
+
+* **Can you share how Outreachy helped enhance your technical and
+ non-technical skills (like communication, project management, etc.)?**
+
+ Technically, I have been able to improve my C programming and bash
+ scripting skills. Also reading and understanding very large codebases
+ like Git. Of course now I can call myself an expert in using Git as a
+ tool itself.
+
+ To contribute to Git, you must be able to communicate well, as all the
+ Git workflows happen remotely and over mailing lists. Most of the time
+ in the Git community it is not about the correctness of your code -- it
+ is about how well you can communicate your rationale to the community
+ before your patches can be accepted. So, over time, as a Git
+ contributor, my communication skills in a technical environment have
+ really improved.
+
+ I have also learnt to write clean code, organize my changes into well
+ formatted patches, and write clear commit messages.
+
+* **What was your biggest takeaway or learning from Outreachy that
+ you now apply regularly in your work?**
+
+ I’d say my biggest takeaway from Outreachy is learning how to write
+ clear, structured commit messages. Git commits, like those in the
+ Linux kernel, follow a thoughtful format: describe the current state,
+ the problem, and the fix. From reading most of the commit messages in
+ Git, you would have understood and been able to visualize what the changes
+ will look like. It also makes it easy to track the changes to other
+ prerequisite commits. I have been using the Git commit messages format
+ in other projects and I really love it.
+
+* **What was the biggest challenge you faced during your contributions
+ to Git, and how did you overcome it?**
+
+ I think the challenge which I initially faced is sending patches to
+ Git, not really a big challenge though as I was able to make my first
+ patch in a few days after joining the community. And the reason is
+ that Git does not use GitHub or GitLab, something someone would have
+ thought they will be using. Git uses a mailing list just like the
+ Linux kernel. While writing this, I remember that I had a challenge
+ retrieving patches from the mailing list as my project depended on some
+ patches that were sent by my mentor previously. I had to use `git am`,
+ something I never used before. Help from my mentor really helped,
+ as well as reading through the "[Hacking Git](https://git.github.io/Hacking-Git/)"
+ page.
+
+* **Have you thought about mentoring new GSoC / Outreachy students?**
+
+ Yeah, I am planning to put in as a mentor for the coming Outreachy
+ period and hopefully for GSoC also. I will be starting as a co-mentor
+ though.
+
+* **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?**
+
+ Smile, I will definitely say the Rustication of some parts of Git
+ which has been going on currently, I think one that has already been
+ integrated to Git is [libgit-rs](https://lore.kernel.org/git/cover.1738187176.git.steadmon@google.com/).
+ Rust seems to be a language that focuses more on safety/security,
+ and safety/security is very important in Git. I am also a Rustacean
+ so I should be able to help hopefully if that happens.
+
+* **If you could remove something from Git without worrying about
+ backwards compatibility, what would it be?**
+
+ I really do not have anything in mind for now.
+
+* **What upcoming features or changes in Git are you particularly
+ excited about?**
+
+ I think it is one of the [GSoC projects by Lucas](https://summerofcode.withgoogle.com/programs/2025/projects/fGgMYHwl).
+ I have been passively following the project. It is about introducing
+ a new Git sub-command (currently intended to be called `git repo-info`)
+ that will centralize data currently retrieved by `git rev-parse` in a
+ JSON format.
+
+* **What is your favorite Git-related tool/library, outside of Git
+ itself?**
+
+ I think it's both GitHub and GitLab -- if I have to choose one, I will say GitHub.
+
+* **What is your toolbox for interacting with the mailing list and for
+ development of Git?**
+
+ I started with [GitGitGadget](https://gitgitgadget.github.io/) initially
+ just to get my patches to the mailing list faster but, along the line
+ I switched to `git send-email` and really, it is more flexible and easy
+ to use than I thought of it. For my machine, I basically use Arch Linux
+ and Neovim as my text editor.
+
+* **How do you envision your own involvement with Git or other open
+ source projects in the future?**
+
+ As I said earlier, open source has really been part of my life and it
+ has really helped me a lot in improving my skills, meeting new people
+ and even making some few bucks through internships. After my
+ internship at Outreachy, I did send patches to the Git community and I
+ planned to keep doing that. After Outreachy, I have contributed to a
+ few other projects like RISC-V and OSIPI (through GSoC). I currently
+ mentor people who want to start their open source journey, and I plan
+ to do more of it. I planned to keep contributing to open source
+ projects and hopefully get a job in open source.
+
+* **What is your advice for people who want to start Git development?
+ Where and how should they start?**
+
+ I have been in many open source projects and see how their workflows
+ are, I will definitely say Git is one of the easiest and most
+ interesting projects to contribute to. The community members are
+ really supportive. Seriously, it is one of the best open source
+ communities I have been to. The best place to start is going through
+ the "[Hacking Git](https://git.github.io/Hacking-Git/)" page. It has
+ all the information on how to start contributing and you can make
+ your first contribution to Git. You should generally start with a
+ microproject which aims to introduce you to the Git contribution
+ workflow. Everything can be found above. Making your first contribution
+ to Git is actually very much easier than you might have thought.
+ Also, do not be scared to ask for help, Git developers are always ready to render help.
+
+* **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?**
+
+ Definitely, Outreachy and GSoC are very much interesting mentoring
+ programs to start your open source journey. They both really make it
+ easy to start contributing to open source. You get assigned to mentors
+ who are experts in open source and the organization. It is a way to get
+ skills you will never be able to get in your classroom and skills
+ needed to thrive and excel in the software engineering world. Apart
+ from skills, it is a way to have proof of work before graduation and
+ also gain global recognition. As I have said, Git is a well known and
+ recognized software project in the whole world, contributing to it is
+ an achievement on its own.
+
+ _Shout session_
+
+ I would like to shout out to all Git contributors, you are doing a
+ great job! I would also like to shout out to my Outreachy mentor
+ Christian Couder, he was really supportive during my Outreachy
+ program! Thanks to the Git Rev teams also!
+
+
+## Other News
+
+__Various__
+
++ [[LWN.net] A set of Git security-fix releases](https://lwn.net/Articles/1029182/)
+ by Jonathan Corbet on LWN\.net, and
+ [Multiple vulnerabilities fixed in Git](https://www.openwall.com/lists/oss-security/2025/07/08/4)
+ by Taylor Blau on oss-security mailing list.
++ [[ANNOUNCE] Git v2.50.1 and friends](https://public-inbox.org/git/xmqqzfdevcov.fsf@gitster.g/t/#u)
+ by Junio C Hamano on the Git mailing list.
++ [Launchpad](https://launchpad.net/) is [phasing out Bazaar code hosting](https://discourse.ubuntu.com/t/phasing-out-bazaar-code-hosting/62189).
+ This post provides a link to the [Migrate a Repository From Bazaar to Git](https://jugmac00.github.io/blog/migrate-a-repository-from-bazaar-to-git/) article.
+
+
+__Light reading__
+
++ [Artisanal Handcrafted Git Repositories](https://drew.silcock.dev/blog/artisanal-git/)
+ by Drew Silcock on drew's dev blog.
+ This article talks about how to handmake your Git repositories without using `git` commands.
+ You might also learn a bit more about how Git works under the hood during the process.
++ [How to use git worktree effectively with Python projects](https://www.andreagrandi.it/posts/how-to-use-git-worktree-effectively-with-python-projects/)
+ (with the help of a simple [git-add-worktree.sh](https://gist.github.com/andreagrandi/542b438bf0017d93aff2b640037e3ce1) Bash script)
+ by Andrea Grandi on his blog.
++ [Managing Multiple Claude Code Sessions Without Worktrees](https://blog.gitbutler.com/parallel-claude-code/)
+ by Scott Chacon on Butler's Log (GitButler Blog).
+ With [Claude Code](https://www.anthropic.com/claude-code)'s new [lifecycle hooks](https://docs.anthropic.com/en/docs/claude-code/hooks),
+ [GitButler](https://gitbutler.com/) Git client auto-sorts simultaneous AI coding into separate branches,
+ without manual [use of `git worktree`](https://www.anthropic.com/engineering/claude-code-best-practices#c-use-git-worktrees).
+ With this feature you can write three features, and get three clean branches.
++ [wtp: A Better Git Worktree CLI Tool](https://dev.to/satococoa/wtp-a-better-git-worktree-cli-tool-4i8l)
+ by Satoshi Ebisawa on DEV\.to.
+ The [wtp](https://github.com/satococoa/wtp) tool was created to make
+ working with multiple tasks in parallel using [Claude Code](https://www.anthropic.com/claude-code)
+ easier than with `git worktree`.
++ [Automated repo maintenance via GitHub Copilot coding agent](https://blog.pamelafox.org/2025/07/automated-repo-maintenance-with-github.html)
+ by Pamela Fox on her Blogger-based blog.
++ [Git Worktrees: Git Done Right](https://www.nickyt.co/blog/git-worktrees-git-done-right-2p7f/)
+ by Nick Taylor on Just Some Dev blog (and also [on DEV\.to](https://dev.to/nickytonline/git-worktrees-git-done-right-2p7f)).
++ [I Lost My Git Stash, So I Built a Tool (VS Code Extension) to Share It](https://dev.to/karandeepsingh7070/i-lost-my-git-stash-so-i-built-a-tool-to-share-it-27bn)
+ by Karandeep Singh on DEV\.to.
++ [Git: share a full repository as a file with `git fast-export`](https://adamj.eu/tech/2025/07/15/git-share-fast-export/)
+ by Adam Johnson on his blog
+ (for some reason the post does not mention the alternative of using
+ [`git bundle`](https://git-scm.com/docs/git-bundle)).
+ + Adam Johnson is the author of "[Boost Your Git DX](https://adamchainz.gumroad.com/l/bygdx)" book,
+ first mentioned in [Git Rev News Edition #104](https://git.github.io/rev_news/2023/10/31/edition-104/),
+ then its updates in [#110](https://git.github.io/rev_news/2024/04/30/edition-110/)
+ and [#119](https://git.github.io/rev_news/2025/01/31/edition-119/).
++ [Conventional Commits makes me sad](https://srazkvt.codeberg.page/posts/2025-07-06-conventional-commits-makes-me-sad.html)
+ by Sarah Mathey on her Codeberg Pages powered Sarah's Website blog.
+ The [Conventional Commits](https://www.conventionalcommits.org/) specification
+ was first mentioned in [Git Rev News Edition #52](https://git.github.io/rev_news/2019/06/28/edition-52/).
++ [Git experts should try Jujutsu](https://pksunkara.com/thoughts/git-experts-should-try-jujutsu/)
+ by Pavan Sunkara on his personal blog.
+ [Jujutsu (`jj`)](https://github.com/martinvonz/jj) is a version control system
+ first mentioned in [Git Rev News Edition #85](https://git.github.io/rev_news/2022/03/31/edition-85/).
++ [Jujutsu For Busy Devs](https://maddie.wtf/posts/2025-07-21-jujutsu-for-busy-devs) and
+ by Madeleine Mortensen on her personal blog.
++ [Using Radicle CI for Development](https://radicle.xyz/2025/07/23/using-radicle-ci-for-development)
+ by Lars Wirzenius on Radicle Blog.
+ [Radicle](https://radicle.xyz/) is the distributed git hosting system,
+ first mentioned in [Git Rev News Edition #49](https://git.github.io/rev_news/2019/03/20/edition-49/).
++ [Cutting GitHub out of the loop](https://www.circusscientist.com/2025/07/23/cutting-github-out-of-the-loop/)
+ (by deploying to a VPS with Git and SSH).
+ Written by tomjuggler on The Circus Scientist Site.
++ [Super Easy* 2-Stage Git Deployment](https://ratfactor.com/cards/super-easy-2-stage-git-deployment)
+ by Dave Gauer on Dave's Virtual Box of Cards.
++ [Guest Post: How I Scanned all of GitHub’s “Oops Commits” for Leaked Secrets](https://trufflesecurity.com/blog/guest-post-how-i-scanned-all-of-github-s-oops-commits-for-leaked-secrets)
+ by Sharon Brizinov on The Dig, the Truffle Security blog.
++ [Top 17 Essential Git Tools for Enhanced Developer Productivity](https://dev.to/vaib/top-17-essential-git-tools-for-enhanced-developer-productivity-7f3)
+ by vAlber on DEV\.to.
+
+
+
+
+__Git tools and sites__
+
++ [DiffX - Next-Generation Extensible Diff Format](https://diffx.org/):
+ describes problem with Unified Diff format, and proposes as a solution
+ a new file format specification for Extensible Diffs,
+ fully backwards-compatible with existing tools,
+ while also being future-proof and remaining human-readable.
++ [git-phoenix](https://github.com/yaitskov/git-phoenix) is a command line tool
+ that does repository recovery after accidental removal or file system failure,
+ using [photorec](https://www.cgsecurity.org/wiki/PhotoRec) (or similar tool).
+ Written in Haskell, under 3-clause BSD license.
++ [wtp (Worktree Plus)](https://github.com/satococoa/wtp) is a Git worktree management tool
+ that extends git's worktree functionality with
+ automated setup, branch tracking, and project-specific hooks.
+ Written in Go, under the MIT license.
++ [GitNifty](https://gitnifty.js.org/index.html) is a robust and promise-based Git utility for Node.js,
+ offering developers smart, automation-ready commands for common Git operations.
+ Created for building CLI tools, automation scripts, or custom Git workflows.
+ Written in TypeScript, and released under the Apache License.
++ [difit](https://github.com/yoshiko-pg/difit) is a CLI tool
+ that lets you view and review local git diffs with a GitHub-style viewer
+ (in a browser). Written in TypeScript, under MIT license.
+ See [difit: Preview GitHub-like diffs locally before you push](https://dev.to/unhappychoice/difit-preview-github-like-diffs-locally-before-you-push-37gc)
+ by Yuji Ueki on DEV\.to.
++ [Flint](https://flintable.com/docs/flint/) is a Git-integrated code formatter
+ that lets each developer work in their preferred style locally,
+ while maintaining a consistent style remotely.
+ By automatically applying “local” and “remote” formatting passes during pull and push operations,
+ Flint prevents formatting noise in commits and code reviews.
+ It is currently in _alpha_ and is available exclusively on npm.
+ Written in Bash, under MIT license.
++ [DotProj](https://dotproj.ac-jr.com/) is a developer-centric CLI tool
+ designed to manage project-specific configuration files with Git versioning.
+ It helps keep your development environment settings organized, versioned, and synchronized
+ across multiple machines and projects.
+ DotProj uses Git commands (commit, push, pull, clone) making it intuitive for developers.
+ Written as a Bash shell script, under MIT license.
++ [git-remote-sqlite](https://github.com/chrislloyd/git-remote-sqlite)
+ is a [Git protocol helper](https://git-scm.com/docs/gitremote-helpers)
+ that helps you store a Git repository in a SQLite database.
+ Written in Zig, under MIT license.
++ [Backlog.md](https://backlog.md/) is a tool that turns any folder with a Git repo
+ into a self-contained project board, powered by plain Markdown files
+ and a zero-config CLI. Written in TypeScript, under MIT license. AI ready.
++ [git-resolve.sh](https://elixir.bootlin.com/linux/v6.16-rc3/source/scripts/git-resolve.sh)
+ is a Bash script that resolves a short git commit ID to its full SHA-1 hash,
+ which is particularly useful for fixing references in commit messages.
+ Under GPL-2.0 license.
++ [GitHub Trends](https://www.githubtrends.io/) is a service that
+ uses the GitHub API to bring you insightful metrics on your contributions,
+ broken by repository and language.
++ [DeepWiki](https://deepwiki.com/): AI-generated docs for any repo.
+ This service turns any public GitHub repo into up-to-date documentation you can talk to
+ (see for example [DeepWiki: git/git](https://deepwiki.com/git/git).
+ DeepWiki is the free public version of [Devin Wiki](https://docs.devin.ai/work-with-devin/devin-wiki) and [Devin Search](https://docs.devin.ai/work-with-devin/devin-search).
+ There are a few similar projects, like
+ [Open Source DeepWiki](https://github.com/AsyncFuncAI/deepwiki-open) and
+ [OpenDeepWiki](https://github.com/AIDotNet/OpenDeepWiki).
++ [GitHub Repository Maintenance Agent](https://github.com/pamelafox/github-repo-maintainer-agent/)
+ is an AI-powered agent for triaging failed [Dependabot](https://docs.github.com/en/code-security/getting-started/dependabot-quickstart-guide) pull requests
+ across one's GitHub repositories. The agent uses [Pydantic AI](https://ai.pydantic.dev/)
+ for LLM-based decisions and the GitHub API for repository, PR, and issue management.
+ Written in Python, under MIT license.
++ [tangled](https://tangled.sh/) is a new social-enabled git collaboration platform
+ built on the [AT Protocol](https://atproto.com/) (that powers the Bluesky social network).
+ Written in Go, under MIT license; note that it is in alpha stage of development.
+ Compare with:
+ + [Radicle](https://radicle.xyz/), a peer-to-peer, local-first code collaboration stack built on Git
+ (first mentioned in [Git Rev News Edition #49](https://git.github.io/rev_news/2019/03/20/edition-49/)).
+ + [ForgeFed](https://forgefed.org/) (formerly GitPub), a federation protocol for software forges
+ (first mentioned in [Git Rev News Edition #69](https://git.github.io/rev_news/2020/11/27/edition-69/)).
+ + [`git-ssb`](https://scuttlebot.io/apis/community/git-ssb.html)
+ (see the [git-ssb-intro](https://github.com/hackergrrl/git-ssb-intro) guide), a
+ decentralized Git repo hosting and issue tracking on [Secure-ScuttleButt (SSB)](https://www.scuttlebutt.nz/)
+ (first mentioned in [Git Rev News Edition #26](https://git.github.io/rev_news/2017/04/19/edition-26/).
+ + [gitstr (`git str`)](https://github.com/fiatjaf/gitstr),
+ a tool to send and receive Git patches
+ over [Nostr](https://nostr.com/), using [NIP-34](https://github.com/nostr-protocol/nips/pull/997)
+ (first mentioned in [Git Rev News Edition #109](https://git.github.io/rev_news/2024/03/31/edition-109/)).
++ [Git With Me](https://sr.ht/~meejah/git-withme/) is a tool for
+ peer-to-peer, encrypted, ephemeral Git collaboration.
+ `git withme` provides a way for a single host to invite numerous peers
+ with short, one-time secure codes. The peers connect directly via
+ [Dilated Magic Wormhole channels](https://meejah.ca/blog/fow-wormhole-forward),
+ allowing collaborators to `git clone git://localhost/`.
++ [Radicle Desktop](https://desktop.radicle.xyz/) is a desktop application
+ that lets you interact with [Radicle](https://radicle.xyz/),
+ a peer-to-peer code collaboration and publishing stack.
+ Written in TypeScript for Node.js and Rust, using the Tauri framework.
+ Under GPLv3 license.
++ [GitBug: Git Learning Simulator](https://github.com/dvig14/gitbug)
+ is a CLI app that teaches Git through hands-on bug fixing.
+ It uses a realistic merge conflict scenario with visual feedback at every step.
+ The goal of the app is to help you learn by doing, not just reading.
+ Written in Python, under MIT license, in early stage (alpha).
+ Compare with:
+ + [Learn Git Branching](https://learngitbranching.js.org/),
+ mentioned first in [Git Rev News Edition #30](https://git.github.io/rev_news/2017/08/16/edition-30/).
+ + [Git Gud](https://nic-hartley.github.io/git-gud/), a visual web-based Git simulator,
+ meant to help understand Git better, announced by its author Nic Hartley in
+ [Git Gud at git](https://dev.to/nichartley/git-gud-at-git-5d9k).
+ First mentioned in [Git Rev News Edition #48](https://git.github.io/rev_news/2019/02/27/edition-48/).
+ + [Git Gud](https://github.com/benthayer/git-gud), a command line game
+ designed to help you learn how to use the Git version control system.
+ Written in Python by Ben Thayer. First mentioned in
+ [Git Rev News Edition #72](https://git.github.io/rev_news/2021/02/27/edition-72/).
+ + [Oh My Git!](https://ohmygit.org/), an open source game about learning Git,
+ written using the Godot game engine ([source](https://github.com/git-learning-game/oh-my-git)).
+ There was a lightning talk about this game at FOSDEM 2021:
+ [Building a Git learning game: A playful approach to version control](https://fosdem.org/2021/schedule/event/git_learning_game/).
+ First mentioned in [Git Rev News Edition #72](https://git.github.io/rev_news/2021/02/27/edition-72/).
+ + [Git-Sim](https://github.com/initialcommit-com/git-sim) tool (written in Python)
+ to visually simulate Git operations in your own repos with a single terminal command.
+ Described in [Git-Sim: Visually Simulate Git Operations In Your Own Repos](https://initialcommit.com/blog/git-sim)
+ (mentioned in [Git Rev News Edition #95](https://git.github.io/rev_news/2023/01/31/edition-95/))
+ and [Git-Sim 3 Month Dev Update: Community Response, New Features, & The Future](https://initialcommit.com/blog/git-sim-3-month-dev-update)
+ (mentioned in [Edition #98](https://git.github.io/rev_news/2023/04/30/edition-98/)).
+ + [Visualize Git](http://git-school.github.io/visualizing-git/) web app
+ that illustrates what's going on under the hood when you use common Git operations,
+ first mentioned in [Git Rev News Edition #107](https://git.github.io/rev_news/2024/01/31/edition-107/).
+ + [Devlands](https://devlands.com/), which is the game that creates
+ immersive experience to help learning Git.
+ First mentioned in [Git Rev News Edition #122](https://git.github.io/rev_news/2025/04/30/edition-122/).
++ [Ferriby](https://github.com/dawedawe/ferriby) is a CLI game
+ where you try to keep Ferrises alive and happy
+ by feeding them commits in your repositories.
+ Written in Rust, under MIT license.
++ [Pride Versioning](https://pridever.org/),
+ a [joking take](https://mastodon.online/@nikitonsky/113691789641950263)
+ on [Semantic Versioning (SemVer)](https://semver.org/).
+
+
+## Releases
+
++ Git [2.50.1 and friends](https://lore.kernel.org/git/xmqq5xg2wrd1.fsf@gitster.g/)
++ Git for Windows [2.50.1(1)](https://github.com/git-for-windows/git/releases/tag/v2.50.1.windows.1),
+[2.50.0(2)](https://github.com/git-for-windows/git/releases/tag/v2.50.0.windows.2),
+[2.49.1](https://github.com/git-for-windows/git/releases/tag/v2.49.1.windows.1)
++ GitHub Enterprise [3.17.4](https://docs.github.com/enterprise-server@3.17/admin/release-notes#3.17.4),
+[3.16.7](https://docs.github.com/enterprise-server@3.16/admin/release-notes#3.16.7),
+[3.15.11](https://docs.github.com/enterprise-server@3.15/admin/release-notes#3.15.11),
+[3.14.16](https://docs.github.com/enterprise-server@3.14/admin/release-notes#3.14.16),
+[3.17.3](https://docs.github.com/enterprise-server@3.17/admin/release-notes#3.17.3),
+[3.16.6](https://docs.github.com/enterprise-server@3.16/admin/release-notes#3.16.6),
+[3.15.10](https://docs.github.com/enterprise-server@3.15/admin/release-notes#3.15.10),
+[3.14.15](https://docs.github.com/enterprise-server@3.14/admin/release-notes#3.14.15),
+[3.17.2](https://docs.github.com/enterprise-server@3.17/admin/release-notes#3.17.2),
+[3.16.5](https://docs.github.com/enterprise-server@3.16/admin/release-notes#3.16.5),
+[3.15.9](https://docs.github.com/enterprise-server@3.15/admin/release-notes#3.15.9),
+[3.14.14](https://docs.github.com/enterprise-server@3.14/admin/release-notes#3.14.14)
++ GitLab [18.2.1, 18.1.3, 18.0.5](https://about.gitlab.com/releases/2025/07/23/patch-release-gitlab-18-2-1-released/),
+[18.2](https://about.gitlab.com/releases/2025/07/17/gitlab-18-2-released/),
+[18.1.2, 18.0.4, 17.11.6](https://about.gitlab.com/releases/2025/07/09/patch-release-gitlab-18-1-2-released/)
++ Gerrit Code Review [3.10.7](https://www.gerritcodereview.com/3.10.html#3107),
+[3.11.4](https://www.gerritcodereview.com/3.11.html#3114),
+[3.12.1](https://www.gerritcodereview.com/3.12.html#3121)
++ GitKraken [11.2.1](https://help.gitkraken.com/gitkraken-client/current/),
+[11.2.0](https://help.gitkraken.com/gitkraken-client/current/),
+[11.1.1](https://help.gitkraken.com/gitkraken-client/current/),
+[11.1.0](https://help.gitkraken.com/gitkraken-client/current/),
+[11.0.0](https://help.gitkraken.com/gitkraken-client/current/)
++ GitHub Desktop [3.5.2](https://desktop.github.com/release-notes/),
+[3.5.1](https://desktop.github.com/release-notes/)
++ Sourcetree [4.2.13](https://product-downloads.atlassian.com/software/sourcetree/ReleaseNotes/Sourcetree_4.2.13.html)
++ GitButler [0.15.8](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.15.8),
+[0.15.7](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.15.7)
++ Sublime Merge [Build 2110](https://www.sublimemerge.com/download)
++ Tower for Mac [13.1](https://www.git-tower.com/release-notes/mac?show_tab=release-notes)
++ Tower for Windows [9.1](https://www.git-tower.com/release-notes/windows?show_tab=release-notes) - [YT video](https://youtu.be/4pNRUz0bNIU)
+
+## Credits
+
+This edition of Git Rev News was curated by
+Christian Couder <>,
+Jakub Narębski <>,
+Markus Jansen <> and
+Kaartic Sivaraam <>
+with help from Usman Akinyemi, brian m. carlson, Aditya Garg,
+Erik-B. Ernst, Bruno Brito and Štěpán Němec.
diff --git a/_posts/2025-08-31-edition-126.markdown b/_posts/2025-08-31-edition-126.markdown
new file mode 100644
index 000000000..2645376d9
--- /dev/null
+++ b/_posts/2025-08-31-edition-126.markdown
@@ -0,0 +1,648 @@
+---
+title: Git Rev News Edition 126 (August 31st, 2025)
+layout: default
+date: 2025-08-31 12:06:51 +0100
+author: chriscool
+categories: [news]
+navbar: false
+---
+
+## Git Rev News: Edition 126 (August 31st, 2025)
+
+Welcome to the 126th 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](http://git.github.io).
+
+This edition covers what happened during the months of July and August 2025.
+
+## Discussions
+
+
+
+
+
+
+### Support
+
+* [[BUG] `git pull` ignores `pull.autostash=true` configuration when used with `--git-dir` and `--work-tree` flags on a bare repository](https://lore.kernel.org/git/010001980c1ee007-2797fc86-fdf3-46e9-bec9-f8da2c9ebb8d-000000@email.amazonses.com/)
+
+ Bryan Lee posted a bug report about the `pull.autostash`
+ configuration variable being ignored in a repository used to manage
+ his dotfiles.
+
+ He expected his unstaged changes to be automatically stashed before
+ a pull when that configuration variable is set to `true`. Instead,
+ the command failed with an error message telling him to "Please
+ commit or stash them". So he thought Git ignored the autostash
+ configuration completely due to the setup, which consisted of a bare
+ repository and a separate work tree accessed through the following
+ alias:
+
+ `$ alias dot='git --git-dir=$HOME/.dotfiles/ --work-tree=$HOME'`
+
+ Lidong Yan replied to Bryan admitting that he wasn't sure why the
+ autostash feature would be ignored when using the `--git-dir` and
+ `--work-tree` flags. He suggested setting `rebase.autostash` instead
+ of `pull.autostash` to `true` though.
+
+ Bryan Lee thanked Lidong saying that `pull.autostash` was not a Git
+ configuration option and that `rebase.autostash` did work for
+ rebase operations. But he raised the issue that Git silently accepts
+ invalid configuration keys without any warning, which can cause
+ users to waste a lot of time debugging.
+
+ Lidong replied with a suggestion to add a `git config verify`
+ subcommand. But Junio Hamano, the Git maintainer, chimed in
+ expressing doubts about such a command, as Git cannot distinguish
+ between a typo of a known variable and a legitimate custom variable
+ that a user or a third-party tool might be using. Lidong elaborated
+ that such a command could work by having Git maintain an internal
+ registry of all valid keys, which could also be extended by users
+ and tools for their own custom configurations.
+
+ Johannes Sixt suggested that instead of building a complex
+ verification system, it would be easier to fix the origin of the
+ misconception that `pull.autostash` was the correct configuration.
+
+ Junio replied to Johannes that having `git pull` pay attention to
+ `rebase.autostash` was at least a documentation failure, if not a
+ bug. He argued that users have different expectations for a
+ relatively safe local rebase compared to a pull from a remote, which
+ could be riskier. Also it didn't make sense for `git pull` to
+ respect `rebase.autostash` but not `merge.autostash`.
+
+ Ben Knoble then chimed in with a counter-argument to Junio. He
+ reasoned that since a `git pull` that rebases is conceptually a
+ fetch followed by a rebase, it would be "far more inconsistent" if
+ it didn't honor the rebase configuration. Breaking that expectation
+ would be unnatural for users taught to think of pull in that
+ way. Following this logic, he also supported the idea that a merging
+ pull should respect `merge.autostash`.
+
+ Then Junio wondered if introducing a new, dedicated `pull.autostash`
+ variable would be a good idea. But soon Lidong came up with
+ [a patch](https://lore.kernel.org/git/20250717030732.75106-1-yldhome2d2@gmail.com/)
+ to actually add this configuration variable.
+
+ Eric Sunshine reviewed the patch and left a number of suggestions to
+ improve it in many ways. After some discussions with Lidong and
+ Junio, Lidong posted
+ [a version 2 of the patch](https://lore.kernel.org/git/20250720124334.12045-1-yldhome2d2@gmail.com/).
+
+ This new version implemented a number of improvements based on the
+ discussion. Some tests were added. The logic was updated to fall
+ back to either `rebase.autostash` or `merge.autostash` depending on
+ whether the pull performed a rebase or a merge. The order of
+ precedence was also clarified: `pull.autostash` now overrides the
+ more general `rebase.autostash` and `merge.autostash`
+ settings. Finally, the documentation was updated with more precise
+ explanations.
+
+ This feature was released recently as part of Git v2.51.0.
+
+## Developer Spotlight: Seyi Kuforiji
+
+_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?**
+
+ My name is Seyi Kuforiji, and I’m an Outreachy alum who worked on
+ [modernizing Git’s unit testing platform](https://seyi-kuforiji-902b48.gitlab.io/posts/week-1-Introduce-yourself)
+ by converting its homegrown unit test framework to use [Clar](https://github.com/clar-test/clar).
+ I studied geography at the University of Lagos, but my curiosity
+ and passion for computers and software drove me to start learning
+ Python and Git immediately after graduating.
+
+ Since then, I’ve enjoyed exploring different areas of IT, from
+ software engineering to data science and DevOps, because I genuinely
+ love learning and experimenting with new tools. I also earned a
+ certification in Health Data Science and Precision Medicine from
+ Stanford University, which reflects my commitment to leveraging
+ technology to improve lives. Participating in Outreachy through Git
+ demonstrated to me the impact of open-source collaboration, and it has
+ strengthened my passion for developing solutions that give back to the
+ community.
+
+ Outside of work, I’m usually diving into something new. Right now, the
+ [Linux graphics stack](https://lwn.net/Articles/955376/) has caught my
+ attention, but when I decide to give my brain a break from tech, I play
+ chess or watch sports.
+
+* **How did you initially become interested in contributing to Git,
+ and what motivated you to choose it as your Outreachy project?**
+
+ Git was one of the first tools I ever learned years ago. At first, I
+ didn’t really understand it; I only knew a few commands like
+ `git clone`, `git add .`, and `git commit -m ""`, and I was
+ living life with just those. I remember during my 12-month software
+ engineering bootcamp, I helped some of my colleagues with Git because
+ I had this so-called “prior knowledge”, and for a while, I was treated
+ like a genius, at least until they caught up!
+
+ So when I saw Git on the list of Outreachy projects, I knew right away
+ that this was where I needed to be: to deepen my understanding of the
+ tool and maybe level up from “genius” to something closer to expert
+ wizardry. These days, some say I’m a wizard, others say I’m a maestro,
+ but I’m just a humble guy who enjoys learning and sharing knowledge.
+
+* **How do you feel your contribution has impacted the Git community
+ or the broader open source ecosystem?**
+
+ My contribution to Git, which was modernizing its homegrown unit
+ testing framework to use Clar, has helped improve Git’s testing
+ capabilities by making the tests more maintainable, easier to
+ understand, and easier to extend to cover more edge cases in the
+ future. Clar brings additional benefits such as clearer test
+ reporting, a more structured way to organize tests, and improved
+ readability, which makes the testing process more approachable for new
+ contributors. While this was primarily an internal-facing improvement,
+ I believe it plays an important role in maintaining the reliability of
+ Git’s functions and operations. A stronger testing framework makes it
+ easier for both new and experienced contributors to work with the
+ codebase confidently, which in turn strengthens Git for the millions
+ of people who rely on it every day.
+
+* **Is there any aspect of Git that you now see differently after
+ having contributed to it?**
+
+ Like I said earlier, I started out only knowing a handful of Git
+ commands to do basic operations. My biggest takeaway since
+ contributing to Git has been discovering the full power of its
+ interactive rebase. I always saw rebase on cheat sheets but never
+ really experienced its capabilities until I worked more deeply with
+ Git. The best way I can describe it is that it feels like a time
+ machine: I make changes and commits, Git captures those states in
+ time, and with interactive rebase, I can go back, rewrite history, and
+ improve it as if it were the first time.
+
+ I still find it so cool that in my text editor, I can see files I had
+ already deleted in later commits come back to life during a rebase. It
+ completely changed how I view Git, not just as a version control
+ system, but as a powerful storytelling tool for code.
+
+* **How do you balance your contributions with other responsibilities
+ like work or school?**
+
+ I usually create a schedule with a clear timeframe dedicated to
+ working on the Git project. For example, during Outreachy, I set aside
+ specific blocks of time each day, treating it almost like a regular
+ job. This helped me stay consistent, avoid distractions, and make
+ steady progress.
+
+ I’ve learned that balancing open-source contributions with other
+ responsibilities is all about structure and prioritization. By
+ planning my week ahead, I can make sure that my work, personal life,
+ and contributions don’t clash. Of course, I also try to stay flexible;
+ some weeks are more demanding than others, but having a framework
+ keeps me grounded and ensures I can keep giving my best to Git.
+
+* **Can you share how GSoC helped enhance your technical and
+ non-technical skills (like communication, project management, etc.)?**
+
+ My C and low-level engineering skills have improved immensely through
+ this experience. I now feel much more confident working in a large and
+ complex codebase, and I’ve built the mindset to take on hard problems
+ without shying away. This confidence is what’s encouraging me to dive
+ deeper into the Linux kernel, where I’ve been learning and
+ experimenting with the graphics stack and GPU drivers. My knowledge of
+ Git itself has also grown significantly, particularly with the
+ interactive rebase functionality, which has completely changed how I
+ think about version control and history management.
+
+ On the non-technical side, I grew a lot in communication and project
+ management. I learned how to break down tasks into smaller, achievable
+ goals, track progress against deadlines, and ask for help effectively
+ when I was stuck. Collaborating with mentors and the wider Git
+ community also taught me the importance of giving clear updates in
+ blog posts and writing thoughtful commit messages.
+
+ Overall, the experience didn’t just make me a better programmer; it
+ made me more disciplined, collaborative, and confident in working on
+ real-world projects.
+
+* **What was your biggest takeaway or learning from Outreachy that
+ you now apply regularly in your work?**
+
+ My biggest takeaway from Outreachy is the balance between
+ understanding deeply and taking action. My mentor encouraged me to not
+ just know how things work but also to dig into why they work. At the
+ same time, I learned that it’s easy to get stuck in the learning
+ phase, waiting until you feel "ready." During my first few weeks, I
+ hesitated too much. What really helped me was realizing that you don’t
+ need to know everything before you start; you just need enough to
+ begin, and the rest comes as you build and iterate. That shift has
+ stayed with me and is something I now apply regularly in my life.
+
+* **What was the biggest challenge you faced during your contributions
+ to Git, and how did you overcome it?**
+
+ One of the biggest challenges I faced was understanding the Git
+ codebase. Git is a very large and complex project with many
+ interconnected parts, and even though my task was limited to the unit
+ testing section, I also needed to understand the underlying
+ functionality being tested. At first, it felt daunting, but I overcame
+ this by burning the midnight candle, digging deeper, and committing
+ myself to continuous learning. Bit by bit, things started to make
+ sense. What really helped was breaking down the complexity into
+ smaller pieces and focusing on one area at a time, while also asking
+ lots of questions and referring back to documentation.
+
+* **Have you thought about mentoring new GSoC / Outreachy students?**
+
+ Yes, I hope to mentor future Outreachy interns if the opportunity arises.
+
+* **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?**
+
+ A first-class graphical interface officially maintained by the Git
+ project, for those who prefer using an app instead of the command
+ line.
+
+* **What upcoming features or changes in Git are you particularly
+ excited about?**
+
+ I’ve been reading recent discussions on the Git mailing list about how
+ Git might evolve in the age of AI, particularly around enabling
+ integrations with AI agents. The idea of extending Git’s capabilities
+ so that AI tools can better understand, interact with, and even
+ automate certain workflows is quite exciting. For example, AI-assisted
+ code reviews, intelligent merge conflict resolution, or automated
+ repository maintenance could become more seamless if Git had
+ standardized ways for agents to plug into its internals.
+
+* **What is your favorite Git-related tool/library, outside of Git
+ itself?**
+
+ GitHub and GitLab.
+
+* **What is your toolbox for interacting with the mailing list and for
+ development of Git?**
+
+ I mostly work from the command line. For sending contributions, I use
+ `git format-patch` and `git send-email`, since I’m more comfortable with
+ CLI tools.
+
+* **How do you envision your own involvement with Git or other open
+ source projects in the future?**
+
+ I intend to remain active in the Git community for many years by
+ making steady contributions. At the moment, I’m still learning and
+ exploring the project to identify areas where I can improve and add
+ value. Over time, I hope to grow into a consistent contributor and
+ take on more responsibility within the project.
+
+* What is your advice for people who want to start Git development?
+ Where and how should they start?
+
+ For anyone starting Git development, I’d recommend a few key
+ resources. The "[Hacking Git](https://git.github.io/Hacking-Git/)”
+ guide is definitely a go-to resource for understanding how the
+ project is structured and how to navigate the codebase.
+ The [MyFirstContribution](https://git-scm.com/docs/MyFirstContribution)
+ page is also very helpful for learning how to get started with making
+ changes. Beyond that, the general Git documentation is valuable for
+ building a solid foundation. Starting small, asking questions, and
+ getting familiar with these resources can make the process much
+ smoother.
+
+* **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?**
+
+ 100% yes. Programs like GSoC and Outreachy give you the unique
+ opportunity to learn directly from some of the smartest and most
+ experienced contributors in the Git community. Having a mentor to
+ guide you through real contributions accelerates your learning, helps
+ you build confidence and good practices early on. I’d absolutely
+ recommend it. My advice would be: come with curiosity, patience, and
+ the willingness to learn. Don’t worry if you don’t understand
+ everything at first. Ask questions, read the documentation, and engage
+ with the community. The mentorship and the experience you gain are
+ invaluable.
+
+
+## Other News
+
+__Various__
+
++ [What’s new in Git 2.51.0?](https://about.gitlab.com/blog/what-s-new-in-git-2-51-0/)
+ by Karthik Nayak on GitLab Blog. It describes performance optimizations
+ for `git push` and `git fetch` (most significant when using the "reftable"
+ backend for references), further plans for Git 3.0 (which can be
+ found in the [BreakingChanges document](https://gitlab.com/gitlab-org/git/-/blob/master/Documentation/BreakingChanges.adoc)), semi-removal of `git whatchanged`
+ (still available with `--i-still-use-this` flag), and marking
+ `git switch` and `git restore` as no longer experimental,
+ adding a new `--start-after` flag for `git for-each-ref` (that can be
+ combined with the `--count` flag to support pagination), etc.
++ [Highlights from Git 2.51](https://github.blog/open-source/git/highlights-from-git-2-51/)
+ by Taylor Blau on GitHub Blog. It describes cruft-free multi-pack indexes
+ (which currently require setting a new `repack.MIDXMustContainCruft` config option),
+ smaller packs with a "path walk" method of collecting objects when repacking
+ (which you can try out with the new `--path-walk` command-line option),
+ a variant of the internal stash representation that can be used for stash interchange
+ (with new `export` and `import` commands for `git stash`), etc.
++ [Xet is now the default storage option for new users and organizations](https://huggingface.co/changelog/xet-default-for-new-users)
+ at [Hugging Face](https://huggingface.co/), switching from [Git LFS](https://git-lfs.com/).
+ This includes moving existing repositories from LFS to Xet.
+ To get the most out of Xet storage [read the usage instructions in the Hub docs](https://huggingface.co/docs/hub/en/storage-backends#using-xet-storage).
+ Note that Xet remains backward compatible with legacy clients optimized for Git LFS.
+ + [XetHub](https://xethub.com/) was first mentioned in passing in
+ [Git Rev News #95](https://git.github.io/rev_news/2023/01/31/edition-95/),
+ and its [benchmark by XetHub against S3, DVC, and Git LFS](https://about.xethub.com/blog/benchmarking-the-modern-development-experience)
+ was mentioned in [Git Rev News Edition #113](https://git.github.io/rev_news/2024/07/31/edition-113/).
+ + Compare with [DagsHub launching Direct Data Access in 2022](https://dagshub.com/blog/launching-data-streaming-and-upload/).
+ [DagsHub](https://dagshub.com/) was first mentioned in
+ [Git Rev News Edition #72](https://git.github.io/rev_news/2021/02/27/edition-72/),
+ then in [#85](https://git.github.io/rev_news/2022/03/31/edition-85/),
+ [#96](https://git.github.io/rev_news/2023/02/28/edition-96/),
+ [#107](https://git.github.io/rev_news/2024/01/31/edition-107/), and
+ [#113](https://git.github.io/rev_news/2024/07/31/edition-113/).
+
+
+__Light reading__
+
++ [The future of large files in Git is Git](https://tylercipriani.com/blog/2025/08/15/git-lfs/)
+ by Tyler Cipriani on his blog. It describes how one can use
+ partial clone today (and large object promisors in the future,
+ which are work in progress) instead of using [Git LFS](https://git-lfs.com/)
+ or similar solutions like [git-annex](https://git-annex.branchable.com/)
+ (or no longer actively developed solutions like git-media and git-fat)
+ or [DVC](https://dvc.org/) (Data Version Control).
++ [Code Review Can Be Better](https://tigerbeetle.com/blog/2025-08-04-code-review-can-be-better/)
+ (than GitHub's default code review process)
+ by matklad (Alex Kladov) on the TigerBeetle blog.
+ Mentions their [`git-review`](https://github.com/tigerbeetle/tigerbeetle/pull/2732)
+ work-in-progress tool, and also the
+ + [Fossil](https://fossil-scm.org/) version control system with built-in project management
+ (first mentioned in [Git Rev News Edition #11](https://git.github.io/rev_news/2016/01/13/edition-11/)), the
+ + [NoteDb](https://gerrit-review.googlesource.com/Documentation/note-db.html) backend
+ for [Gerrit](https://www.gerritcodereview.com/) - which allows storing review state in Git,
+ (NoteDb was first mentioned in [Git Rev News Edition #40](https://git.github.io/rev_news/2018/06/20/edition-40/)), the
+ + [git-bug](https://github.com/git-bug/git-bug) tool that uses Git to store information about issues / bugs
+ (first mentioned in [Git Rev News Edition #43](https://git.github.io/rev_news/2018/09/19/edition-43/)), the
+ + [git-appraise](https://github.com/google/git-appraise) tool that uses Git to store information about reviews
+ (first mentioned in [Git Rev News Edition #11](https://git.github.io/rev_news/2016/01/13/edition-11/)), the
+ + [prr](https://doc.dxuuu.xyz/prr/index.html) ('pull request review') tool that brings mailing list style code reviews to GitHub PRs
+ (mentioned in [Git Rev News Edition #90](https://git.github.io/rev_news/2022/08/31/edition-90/)), the
+ + [git-pr](https://pr.pico.sh/) project that leverages Git native features to replace the entire pull request workflow,
+ (mentioned in [Git Rev News Edition #113](https://git.github.io/rev_news/2024/07/31/edition-113/)), and the
+ + [How Jane Street Does Code Review](https://www.janestreet.com/tech-talks/janestreet-code-review/)
+ article by Ian Henry on Jane Street Tech Talks site.
++ [Jujutsu + Radicle = ❤️](https://radicle.xyz/2025/08/14/jujutsu-with-radicle)
+ by fintohaps on Radicle Blog, describing how the author uses Jujutsu in tandem with Radicle.
+ + [Jujutsu (`jj`)](https://jj-vcs.github.io/jj/) is a Git-compatible version control system
+ written in Rust, and was first mentioned in
+ [Git Rev News Edition #85](https://git.github.io/rev_news/2022/03/31/edition-85/).
+ + [Radicle](https://radicle.xyz/), a peer-to-peer, local-first code collaboration stack built on Git,
+ was first mentioned in [Git Rev News Edition #49](https://git.github.io/rev_news/2019/03/20/edition-49/).
++ [introducing spindle](https://blog.tangled.sh/ci) by Anirudh & Akshay on Tangled blog;
+ spindle is Tangled’s new CI runner built atop Nix and the AT Protocol.
+ + [Tangled.sh](https://blog.tangled.sh/intro) is a new social-enabled Git collaboration platform
+ built on top of the AT Protocol (which is behind [BlueSky](https://bsky.app/)
+ microblogging federated social media service).
+ First mentioned in [the previous edition of Git Rev News](https://git.github.io/rev_news/2025/07/31/edition-125/).
+ + Compare the [Using Radicle CI for Development](https://radicle.xyz/2025/07/23/using-radicle-ci-for-development)
+ article by Lars Wirzenius, also mentioned in [Git Rev News #125](https://git.github.io/rev_news/2025/07/31/edition-125/).
+ [Radicle](https://radicle.xyz/) is another distributed Git hosting system,
+ first mentioned in [Git Rev News Edition #49](https://git.github.io/rev_news/2019/03/20/edition-49/).
++ [How we used Radicle with GitHub Actions](https://radicle.xyz/2025/05/30/radicle-with-github-actions):
+ Quick guide to trying Radicle without dropping GitHub or whatever CI you’re using.
+ Published by rudolfs (Rūdolfs Ošiņš) on Radicle Blog.
++ [Archive Legacy GitHub Repos with Subtree](https://dev.to/tonymet/archive-legacy-github-repos-with-subtree-1dj3)
+ by Tony Metzidis on DEV\.to, about how to use `git subtree` to consolidate
+ hundreds of legacy experimental repos into an archive,
+ preserving all of the commit history.
++ [I'll think twice before using Github Actions again](https://ninkovic.dev/blog/2025/think-twice-before-using-github-actions)
+ by Nemanja Ninković on their blog.
++ [Git without a forge](https://www.chiark.greenend.org.uk/~sgtatham/quasiblog/git-no-forge/)
+ by Simon Tatham on his quasiblog, describing how to interact with a bare Git repo,
+ and explaining why he personally does not use any of the Git forges.
++ [How I Cleaned Up My Git History Like a Boss (a.k.a. Fixing Wrong Author Emails)](https://dev.to/emrahg/how-i-cleaned-up-my-git-history-like-a-boss-aka-fixing-wrong-author-emails-19lb)
+ by Emrah G. on DEV\.to. The solution uses the (deprecated) `git filter-branch` tool;
+ the recommended replacement is [`git filter-repo`](https://github.com/newren/git-filter-repo).
+ Also, you can correct the _visible_ e-mail with the [`.mailmap`](https://git-scm.com/docs/gitmailmap) file
+ (changing what Git shows, without having to rewrite history).
++ [Revolutionizing Git Workflows: The MCP Git Commit Generator](https://www.bampouris.eu/blog/mcp-git-commit-generator/)
+ by Theoklitos Bampouris on his blog (and also [on DEV\.to](https://dev.to/theoklitosbam7/revolutionizing-git-workflows-the-mcp-git-commit-generator-530m)),
+ about using Agentic AI and an LLM chatbot,
+ leveraging the [Model Context Protocol (MCP)](https://modelcontextprotocol.io/introduction).
+ The generated commit message will follow [Conventional Commits](https://www.conventionalcommits.org/) conventions.
+ Note: please read the proposed commit message before accepting it,
+ especially for more complex changes. While AI agents can take information
+ from changes and from an issue tracker, they cannot write whys of the change;
+ they cannot access your thoughts.
+ + [Git Rev News Edition #97](https://git.github.io/rev_news/2023/03/31/edition-97/)
+ lists a few other tools that use the GPT-3 / ChatGPT Large Language Model (LLM)
+ to help write commit messages.
++ [Better git status](https://purpleidea.com/blog/2025/08/04/better-git-status/)
+ by James (@purpleidea) on his blog. He uses `git alias` which examines
+ the terminal width, and then `git status --column=nodense` if the terminal is wide enough.
++ [Some Pretty Cool Git Tools To Save Your Sanity](https://fev.al/posts/git-tools/)
+ by Charles Féval on his blog.
+ Mentions `git revise` for splitting pull requests (PRs),
+ and custom `git backup`, `git reparent`, `git split`, `git move-branch`, and `git bookmark` commands.
++ [Using Git worktrees for development](https://blog.kulman.sk/git-worktree/)
+ by Igor Kulman on his blog.
++ [Curing A Case Of Git-UX](https://oppi.li/posts/curing_a_case_of_git-UX/)
+ by Akshay on their blog; describes how one can improve git worktree UX
+ with the help of [fzf](https://github.com/junegunn/fzf)
+ (or [skim](https://github.com/lotabout/skim) or [fzy](https://github.com/jhawthorn/fzy)),
+ and shell functions.
+ + See also [Improving shell workflows with fzf](https://seb.jambor.dev/posts/improving-shell-workflows-with-fzf/),
+ mentioned in [Git Rev News Edition #74](https://git.github.io/rev_news/2021/04/30/edition-74/).
++ [Making my GitHub heatmap widget](https://leanrada.com/notes/github-heatmap-widget/) by
+ Lean Rada on their blog. The created tool partially scrapes and reformats HTML input,
+ but is constructed in such way that it could consume JSON from GitHub API instead.
++ [TryHackMe - Git Happens](https://jacen.moe/blog/20250805-tryhackme-git-happens/)
+ by Jacen Sekai on his blog, about [Git Happens](https://tryhackme.com/room/githappens):
+ an easy-ranked box on [TryHackMe](https://tryhackme.com/), website for
+ hands-on cyber security training through real-world scenarios.
++ [The Ingredients of a Productive Monorepo](https://blog.swgillespie.me/posts/monorepo-ingredients/)
+ by Sean Gillespie on his blog.
+ + You can find a definition of "monorepo" and a list of various tools on the [Monorepo.tools](https://monorepo.tools/) site,
+ which was first mentioned in [Git Rev News Edition #84](https://git.github.io/rev_news/2022/02/28/edition-84/).
++ [Git Branching Explained: Base, Topic, and Parent Branches](https://www.git-tower.com/blog/base-topic-parent-branches)
+ by Bruno Brito on Tower Blog.
++ [Git and jujutsu: in miniature](https://lottia.net/notes/0013-git-jujutsu-miniature.html)
+ by Charlotte (lottia) on her blog (2024).
++ [Git Interactive Rebase TODO Order is Wrong](https://salferrarello.com/git-interactive-rebase-order-is-wrong/)
+ by Sal Ferrarello on his blog (2019), stating a personal preference for stack-like order,
+ with latest commits appearing on the top.
+ The author even wrote a Vim plugin,
+ [Interactive Rebase Reverse Vim](https://github.com/salcode/vim-interactive-rebase-reverse),
+ to reverse the order of the commits in an interactive `git rebase`.
++ [Every line of code is always documented](https://mislav.net/2014/02/hidden-documentation/)
+ by Mislav Marohnić on his blog (2014). The article describes how to
+ extract information about a code snippet from project history using `git blame`,
+ 'pickaxe' search with `git log -S`, and a
+ [git-churn](https://github.com/garybernhardt/dotfiles/blob/f0c0ff92209e5aed4fa3ef6faf056eb9944a8f12/bin/git-churn) script,
+ and how to stay on the right side of history
+ (among others, to be able to use this technique effectively).
+
+
+
+
+__Git tools and sites__
+
++ [WRKFLW](https://github.com/bahdotsh/wrkflw) is a command-line tool
+ for validating and executing GitHub Actions workflows locally,
+ without requiring a full GitHub environment.
+ It helps developers test their workflows directly on their machines
+ before pushing changes to GitHub.
+ Written in Rust, under MIT license.
+ + Compare with the [Act](https://github.com/nektos/act) command line tool
+ to run your GitHub Actions locally, using the Docker Engine API.
+ Written in Go, under MIT license.
+ Mentioned in [Git Rev News Edition #113](https://git.github.io/rev_news/2024/07/31/edition-113/).
++ [Setup DVC Action](https://github.com/marketplace/actions/setup-dvc-data-version-control)
+ by Iterative is a JavaScript action that can be used as a step in GitHub Actions.
+ [DVC](https://dvc.org) (Data Version Control) was first mentioned
+ in [Git Rev News Edition #42](https://git.github.io/rev_news/2018/08/22/edition-42/)
+ and many times since (most recently in [Edition #116](https://git.github.io/rev_news/2024/10/31/edition-116/)).
++ [Lappverk](https://codeberg.org/natkr/lappverk/) is a tool for modifying other people's software.
+ It works by keeping a series of `.patch` files as its source of truth
+ (like [quilt](https://savannah.nongnu.org/projects/quilt)),
+ but using temporary Git repositories as an interface to modify the patches,
+ rather than implementing its own version control system from scratch.
+ Written in Rust, under Apache 2.0 License.
+ Started out as Patchable internal tool.
+ You might also be interested in reading the announcement blog post:
+ [Modifying Other People's Software](https://natkr.com/2025-08-14-modifying-other-peoples-software/)
+ by Natalie Klestrup Röijezon (natkr) on natkr's ramblings.
+ + Compare [patchwork](http://jk.ozlabs.org/projects/patchwork/) - a web-based patch tracking system
+ designed to facilitate contribution and management of contributions to an open-source project,
+ first mentioned in [Git Rev News Edition #20](https://git.github.io/rev_news/2016/10/19/edition-20/).
+ + Compare [Stacked Git (StGit)](https://stacked-git.github.io/),
+ an application for managing Git commits as a stack of patches,
+ first mentioned in [Git Rev News Edition #17](https://git.github.io/rev_news/2016/07/20/edition-17/).
+ + Compare [B4 Tools](https://github.com/mricon/b4), a helper utility
+ to work with patches made available via a [public-inbox](https://public-inbox.org/README.html) archive like [lore.kernel.org](https://lore.kernel.org/).
+ This tool is written to make it easier to participate in patch-based workflows,
+ like those used in the Linux kernel development.
+ First mentioned in [Git Rev News Edition #61](https://git.github.io/rev_news/2020/03/25/edition-61/).
++ [patch-hub](https://github.com/kworkflow/patch-hub/tree/unstable) is a TUI tool
+ that streamlines the interaction of Linux developers
+ with patches archived on [lore.kernel.org](https://lore.kernel.org/).
+ Written in Rust, under GPL 2.0 license.
+ It is a spin-off of [kw](https://github.com/kworkflow/kworkflow),
+ a tool for helping Linux kernel developers in everyday tasks
+ (which is written in shell, and is under GPL 2.0 license).
++ [GitGenius](https://selvaneyas.github.io/gitgenius) is a smart and simple CLI tool
+ that explains Git errors in plain English and helps you fix them quickly.
+ Written in Python, under MIT license.
+ + See also [thefuck](https://github.com/nvbn/thefuck), a command line application
+ which corrects your previous console command (for example Git command)
+ if you made an error (like typos in command name), and it _didn't_ do what you wanted;
+ the tool was first mentioned in [Git Rev News Edition #101](https://git.github.io/rev_news/2023/07/31/edition-101/).
+ + Compare the [Oh Shit, Git!?!](http://ohshitgit.com/) / [Dangit, Git!?!](https://dangitgit.com/)
+ website by Katie Sylor-Miller,
+ first mentioned in [Git Rev News Edition #19](https://git.github.io/rev_news/2016/09/14/edition-19/).
++ [GIT.WTF!?!](https://git.wtf/) is a website with articles in which you can
+ find solutions to your Git problems,
+ along with tips & tricks to improve your Git workflows.
++ [GITHUB2FORGEJO](https://github.com/PatNei/GITHUB2FORGEJO)
+ is a Bash script for migrating all repositories from a GitHub user account
+ to a specified Forgejo instance. It supports mirroring or one-time cloning
+ and includes a cleanup feature for removing repositories on Forgejo
+ that no longer exist on GitHub.
+ Under GPL 3.0 license.
+ Based on [GitHub2Forgejo](https://github.com/RGBCube/GitHub2Forgejo)
+ Nushell script, also under GPL 3.0 license.
+ + [Forgejo](https://forgejo.org/) is a self-hosted lightweight software forge,
+ which started as a “soft” fork of Gitea (itself a fork of Gogs),
+ and was first mentioned in passing in [Git Rev News Edition #103](https://git.github.io/rev_news/2023/09/30/edition-103/).
++ [git-revise](https://git-revise.readthedocs.io/) is a Git subcommand and Python library
+ for efficiently updating, splitting, and rearranging commits.
+ Under MIT License.
+ The [Introducing git-revise](https://mystor.github.io/git-revise.html)
+ blog post was mentioned in [Git Rev News Edition #54](https://git.github.io/rev_news/2019/08/21/edition-54/).
++ [git-tools](https://github.com/cfe84/git-tools) is a set of additional Git commands
+ to "help you make crazy stuff in a very unsafe way".
+ Includes `git backup`, `git move-branch`, `git reparent` (similar to `git rebase --onto`),
+ `git split`, `git bookmark`, `git newbranch`, and `git get`.
+ Written in Go, under GPL 2.0 license.
++ [git-fetch-file](https://github.com/andrewmcwattersandco/git-fetch-file) is a utility
+ for importing specific files from other Git repositories into your own project,
+ while keeping a manifest (`.git-remote-files`) that remembers where they came from
+ and what commit they belong to.
+ Written in Python, under GPL 2.0 license.
++ [git-word-blame](https://framagit.org/mdamien/git-word-blame)
+ is a tool that shows word-by-word authors of a file, creating TSV and HTML files.
+ Written in Python, under GPL 3.0 license.
+ The README includes links to a few alternative tools in the "See also" section.
++ [`gguser`](https://github.com/withshubh/gguser) is a CLI tool
+ to easily switch between different Git user profiles.
+ It simplifies managing multiple GitHub or GitLab accounts
+ by allowing users to switch between profiles effortlessly.
+ Written in JavaScript for Node.js (npm), under Apache 2.0 License.
++ [GitLabForm](https://gitlabform.github.io/gitlabform/) is a specialized configuration-as-code tool
+ for GitLab's application settings, groups, projects, and more,
+ using hierarchical configuration written in YAML.
+ Written in Python, under MIT license.
+ See the [GitlabForm for Gitlab repository automation](https://www.mikestreety.co.uk/blog/gitlabform-for-gitlab-repository-automation/)
+ blog post by Mike Street on his blog.
++ [`gmap`](https://github.com/seeyebe/gmap) is a fast command-line tool
+ (with terminal interface) to explore Git activity - heatmaps, churn, authorship, and more.
+ It helps you understand your Git repository at a glance - not just what changed,
+ but when, how much, and by whom.
+ Written in Rust, under MIT license.
++ [Ayllu](https://ayllu-forge.org/) is a code forge optimized for single instance deployments.
+ It is still a work in progress. Written in Rust, under AGPL license.
++ [DiffMem](https://github.com/Growth-Kinetics/DiffMem) is a lightweight,
+ Git-based memory backend designed for AI agents and conversational systems.
+ It uses Markdown files for human-readable storage,
+ Git for tracking temporal evolution through differentials,
+ and an in-memory BM25 index for fast, explainable retrieval.
+ This project is a proof-of-concept (PoC).
+ Written in Python, no license (!).
+
+
+## Releases
+
++ Git [2.51.0](https://lore.kernel.org/git/xmqqikikk1hr.fsf@gitster.g/),
+[2.51.0-rc2](https://lore.kernel.org/git/xmqqh5ybcfwt.fsf@gitster.g/),
+[2.51.0-rc1](https://lore.kernel.org/git/xmqqikizoybn.fsf@gitster.g/),
+[2.51.0-rc0](https://lore.kernel.org/git/xmqqms8f5889.fsf@gitster.g/)
++ Git for Windows [v2.51.0(1)](https://github.com/git-for-windows/git/releases/tag/v2.51.0.windows.1),
+[v2.51.0-rc2(1)](https://github.com/git-for-windows/git/releases/tag/v2.51.0-rc2.windows.1),
+[v2.51.0-rc1(1)](https://github.com/git-for-windows/git/releases/tag/v2.51.0-rc1.windows.1),
+[v2.51.0-rc0(1)](https://github.com/git-for-windows/git/releases/tag/v2.51.0-rc0.windows.1)
++ GitLab [18.3.1, 18.2.5, 18.1.5](https://about.gitlab.com/releases/2025/08/27/patch-release-gitlab-18-3-1-released/),
+[18.3](https://about.gitlab.com/releases/2025/08/21/gitlab-18-3-released/),
+[18.2.4](https://about.gitlab.com/releases/2025/08/18/gitlab-18-2-4-released/),
+[17.11.7](https://about.gitlab.com/releases/2025/08/15/gitlab-17-11-7-released/),
+[18.2.2, 18.1.4, 18.0.6](https://about.gitlab.com/releases/2025/08/13/patch-release-gitlab-18-2-2-released/)
++ Gerrit Code Review [3.10.8](https://www.gerritcodereview.com/3.10.html#3108),
+[3.11.5](https://www.gerritcodereview.com/3.11.html#3115),
+[3.12.2](https://www.gerritcodereview.com/3.12.html#3122)
++ GitHub Enterprise [3.17.5](https://docs.github.com/enterprise-server@3.17/admin/release-notes#3.17.5),
+[3.16.8](https://docs.github.com/enterprise-server@3.16/admin/release-notes#3.16.8),
+[3.15.12](https://docs.github.com/enterprise-server@3.15/admin/release-notes#3.15.12),
+[3.14.17](https://docs.github.com/enterprise-server@3.14/admin/release-notes#3.14.17)
++ GitKraken [11.3.0](https://help.gitkraken.com/gitkraken-client/current/)
++ Git Cola [4.14.0](https://github.com/git-cola/git-cola/releases/tag/v4.14.0)
++ GitButler [0.15.16](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.15.16),
+[0.15.15](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.15.15)
++ Sublime Merge [Build 2112](https://www.sublimemerge.com/download)
++ Tower for Mac [14](https://www.git-tower.com/blog/tower-mac-14) ([YouTube video](https://youtu.be/WYhtxBAzOB0))
++ Kinetic Merge [1.9.0](https://github.com/sageserpent-open/kineticMerge/releases/tag/v1.9.0)
+
+## Credits
+
+This edition of Git Rev News was curated by
+Christian Couder <>,
+Jakub Narębski <>,
+Markus Jansen <> and
+Kaartic Sivaraam <>
+with help from Štěpán Němec, Gerard Murphy,
+Seyi Kuforiji and Bruno Brito.
diff --git a/_posts/2025-09-30-edition-127.markdown b/_posts/2025-09-30-edition-127.markdown
new file mode 100644
index 000000000..bf5ec5474
--- /dev/null
+++ b/_posts/2025-09-30-edition-127.markdown
@@ -0,0 +1,475 @@
+---
+title: Git Rev News Edition 127 (September 30th, 2025)
+layout: default
+date: 2025-09-30 12:06:51 +0100
+author: chriscool
+categories: [news]
+navbar: false
+---
+
+## Git Rev News: Edition 127 (September 30th, 2025)
+
+Welcome to the 127th 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](http://git.github.io).
+
+This edition covers what happened during the months of August and September 2025.
+
+## Discussions
+
+
+
+
+
+### Support
+
+* [Doing blobless clone by default; switching between blobless, treeless and full clones by a command](https://lore.kernel.org/git/79ed51fbd94ec2793ab0388b33963b366e48c590.camel@aegee.org/)
+
+ Dilyan Palauzov (Дилян Палаузов) sent an email to the Git mailing
+ list where he proposed making blobless cloning
+ (`--filter=blob:none`) the default behavior for `git clone` via a
+ global configuration option. He also suggested adding a command to
+ download all locally missing history, a command to convert a
+ repository to a pure treeless or pure blobless clone, and a config
+ option to make blobless clone the default behavior when running just
+ `git clone `.
+
+ He said that most users used `git clone` to build or change software, not to
+ immediately analyze history with commands like `git log`. Therefore,
+ a reduced data download would speed up initialization, save
+ bandwidth, and reduce server load.
+
+ Kristoffer Haugsbakk replied saying the proposed command to
+ "download all locally missing history" for treeless and blobless
+ clones "sounds like git-backfill(1)". He also noted that he had
+ "never used blob/treeless" clones himself.
+
+ Derrick Stolee, who likes to be called just "Stolee", and who
+ contributed the `git backfill` command, replied to Kristoffer
+ confirming that `git backfill` is intended to assist with downloading
+ the missing blobs in a blobless partial clone.
+
+ About treeless clones though, he noted that `git backfill` is not
+ optimized for them, and that treeless clones are generally not
+ intended for "refilling," as downloading missing trees is
+ "particularly expensive".
+
+ Stolee suggested using `scalar clone`, which is already shipped with
+ Git, instead of making blobless cloning the default, as
+ `scalar clone` was contributed partly to allow users to opt into a
+ version of `git clone` that incorporates "best practices and
+ advanced features as they are developed", while `git clone`
+ maintains backward compatibility. He recognized that `scalar clone`
+ might not be "discoverable enough" though.
+
+ Junio Hamano replied to Stolee's suggestion that a future command
+ like `git big-clone` could emerge from the feedback on
+ `scalar clone`. He said a separate command like `git big-clone`
+ would not be discoverable enough either. Instead as a new feature
+ matures, it should be a welcome change for `git clone` to borrow it
+ as a new option. Such optimizations (like those for large repos)
+ could be automatically enabled based on the repository's size,
+ provided it was done with end-user consent.
+
+ Patrick Steinhardt replied to Stolee about treeless clones. He
+ agreed that the existing command `git backfill` is not optimized for
+ refilling treeless clones, and proposed an idea to backfill trees by
+ batching based on depth, but concluded that this method was
+ "definitely not ideal" and would perform "way worse compared to
+ backfilling blobs".
+
+ Patrick also said that for these reasons he generally recommends not
+ to use treeless clones at all.
+
+ Stolee replied to Patrick agreeing with the general caution
+ regarding treeless clones, and that they were "not a good approach
+ for doing ongoing work as a human".
+
+ However he noted that they are useful if a user needs the speed of a
+ shallow clone combined with the ability to analyze commit history
+ (though with no path history) for an "ephemeral scenario like a CI
+ build". But they are a "tool for a very narrow case" and should only
+ be used by those who understand how to avoid their pitfalls. Patrick
+ then agreed with that point of view.
+
+ Konstantin Ryabitsev, the system administrator for kernel.org,
+ replied to the original email from Dilyan about making blobless
+ clones the default behavior for `git clone`. He said a
+ counter-rationale to this proposal was that shallow clones (which
+ include blobless clones) generate significantly more load on the
+ server side.
+
+ The reason is that for these partial clones, no pre-existing packs
+ are available for the operation, requiring more computation from the
+ server. So changing the default behavior for `git clone` could
+ likely result in slower clones for everyone and lead to more
+ unavailable servers due to the high load.
+
+ Ben Knoble also replied to Dilyan's original email by opposing the
+ proposal to make blobless clones the default behavior while agreeing
+ that managing this preference via a config option was a reasonable
+ compromise.
+
+ Ben's opinion was that such a default behavior would defeat the
+ "tremendous advantage of distributed version control", which is about
+ having the whole repository available independently. It would also
+ make some of his use cases more difficult as he frequently clones
+ repositories specifically to run "history spelunking searches".
+
+ He noted that he primarily deals with repositories where the issue
+ isn't about clones, but about mismanaging large binary files in
+ history, which causes large blobs and clone times.
+
+## Developer Spotlight: Toon Claes
+
+* **Who are you and what do you do?**
+
+ I'm Toon from Belgium. My name is pronounced like "tone" (rhymes with
+ "bone"), and not like the "toon" in "cartoon", but usually I'm already
+ happy if people remember my name 😉.
+
+ I'm employed by GitLab for more than 8 years, and since late 2024 I've
+ been part of the Git team, contributing to the Git project. I've started
+ my professional career in 2008 building software for a payment terminal
+ running embedded GNU/Linux using C & C++. Later I've transitioned into
+ doing web and mobile development for a while. And now recently, I've
+ been circling back to more lower-level programming, contributing to Git
+ using C.
+
+* **What would you name your most important contribution to Git?**
+
+ I'm fairly new in the Git community, but recently I've been working on
+ adding [`git last-modified`(1)](https://git.github.io/htmldocs/git-last-modified.html).
+ It's a sub-command that will be released in Git v2.52. This command
+ finds the commit that last modified each path in a tree. It can
+ be used on forges (like GitLab, GitHub, Codeberg), to show commit
+ data in a tree view.
+
+* **What are you doing on the Git project these days, and why?**
+
+ The subcommand [`git last-modified`(1)](https://git.github.io/htmldocs/git-last-modified.html)
+ was recently merged in the 'master'. But there's more work to be
+ done to improve its performance.
+
+* **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?**
+
+ Once data is committed to Git, and it's made part of the history (i.e.
+ committed or merged into the default branch), it's trapped forever. This
+ is a core principle of Git: you cannot rewrite history without changing
+ commit hashes. This is very powerful, but also problematic in some
+ scenarios.
+
+ For example, at my $DAYJOB we receive commonly the request from
+ customers to remove confidential or sensitive information from a Git
+ repository. This is not possible without rewriting history. Or when, by
+ accident, large files are committed to Git, you cannot get them out
+ (without rewriting history). Or people might want to remove/change
+ their personal information in a repository, for example when they
+ transition genders.
+
+ Can we (and should we?) build something that removes and overwrites
+ pieces of history, without changing commit hashes? It's a slippery
+ slope, because from experience I know Git users are very creative and
+ might use this feature in ways it was not intended for.
+
+* **If you could remove something from Git without worrying about
+ backwards compatibility, what would it be?**
+
+ The use of the double `..` and triple `...` dot notation in
+ [`gitrevisions(7)`](https://git-scm.com/docs/gitrevisions#_dotted_range_notations)
+ and `git diff(1)`. I even once ranted about it in [a video](https://www.youtube.com/watch?v=phThP8DwJVs).
+
+* **What is your favorite Git-related tool/library, outside of
+ Git itself?**
+
+ I'm a big fan of [Magit][1]. It's arguably the best tool to interact
+ with Git and I also learned a lot from it. I consider myself an
+ advanced Git user, but I wouldn't be able to split up changes in
+ several commits without [Magit][1].
+
+[1]: https://magit.vc/
+
+* **Do you happen to have any memorable experience w.r.t. contributing
+ to the Git project? If yes, could you share it with us?**
+
+ One of my earliest contributions to Git was a bug fix in the code used
+ by `git bundle create`. We noticed sometimes references didn't end up in
+ the bundle. After a lot of digging I submitted a patch that removed
+ about 30 lines of code written way back in 2007. The code from 2007
+ caused references to be skipped if they were modified while the
+ `git bundle create` process was running. But it wasn't needed anymore
+ due some changes made in 2013, although no one ever realized that.
+ You can read more about it [in the patch][2].
+
+ It was really satisfying to submit a patch that was nothing more than
+ code deletion of really old code (and adding some tests). And it taught
+ me to write a good commit message, which I was praised for by
+ [the maintainer][3]. It was a very nice experience as a newcomer in the
+ community.
+
+[2]: https://lore.kernel.org/git/20241211-fix-bundle-create-race-v3-1-0587f6f9db1b@iotcl.com/
+[3]: https://lore.kernel.org/git/xmqqzfl4l22t.fsf@gitster.g/
+
+* **What is your toolbox for interacting with the mailing list and for
+ development of Git?**
+
+ I mostly live in Emacs and my terminal (zsh). I consume email in Emacs
+ using [notmuch][4]. To submit patches I use [b4][5], which I also
+ sometimes use to pull in patches. But I also sometimes pull in
+ the branches from [Junio's fork][6] or the fork shared across
+ my colleagues.
+
+ In Git, I compile and unit test changes using Meson. Its use was
+ introduced in the Git project around the [end of 2024][7]. It's
+ reliable because it prevents me from forgetting to recompile
+ before running tests; it's fast because it parallelizes compilation
+ by default and automatically [uses Ccache][8]; it allows out-of-tree
+ builds, which is really convenient if you want to benchmark various
+ revisions of Git.
+
+[4]: https://notmuchmail.org/doc/latest/notmuch-emacs.html
+[5]: https://github.com/mricon/b4
+[6]: https://github.com/gitster/git
+[7]: https://lore.kernel.org/git/20241206-pks-meson-v11-0-525ed4792b88@pks.im/
+[8]: https://mesonbuild.com/Feature-autodetection.html#ccache
+
+* **What is your advice for people who want to start Git development?
+ Where and how should they start?**
+
+ Learn to navigate [the mailing list archive][9]. It lacks structure so
+ things can be hard to find, but there's so much information up there. If
+ you're interested in a topic, or you think you've found the bug, start digging.
+ Use [`git blame(1)`][10] to find the commit that introduced the changes
+ and look up the conversation around it in the mailing list archive.
+ This will help you understand why some decisions are made. Also it
+ familiarizes you with the people in the community, how they think,
+ how they communicate, and what's expected from you. Having the
+ knowledge from those conversations can help you build a strong case
+ whenever you're submitting a feature change or bug fix.
+
+[9]: https://lore.kernel.org/git
+[10]: https://git-scm.com/docs/git-blame
+
+
+## Other News
+
+__Various__
+
++ [What’s next for Git? 20 years in, the community is still pushing forward](https://github.blog/open-source/whats-next-for-git-20-years-in-the-community-is-still-pushing-forward/)
+ by Lee Reilly on GitHub Blog - mainly about
+ the [Git Merge 2025 talks lineup](https://git-merge.com/#speakers).
++ [Git Developers Debate Making Rust Mandatory](https://www.phoronix.com/news/Git-Weighs-Mandatory-Rust)
+ by Michael Larabel on Phoronix.
++ [A policy for `Link:` tags](https://lwn.net/Articles/1037069/) (for Linux),
+ by Jonathan Corbet on LWN\.net.
++ [Working almost continuously for six months](https://www.linkedin.com/feed/update/urn:li:activity:7378744230275350528/), Yasin Dehfuli completed the [Persian translation of the ProGit book](https://git-scm.com/book/fa/v2).
++ An initiative [to refresh the look and content of https://git-scm.com/](https://github.com/git/git-scm.com/issues/2046) has been kicked off by Toon Claes. Contributions welcome, especially from visual designers!
+
+
+__Light reading__
+
++ [git-flow-next: The Next Iteration of Advanced Git Workflows](https://www.git-tower.com/blog/git-flow-next)
+ by Bruno Brito on Tower Blog.
++ [A kludgy new way to git-blame](https://benknoble.github.io/blog/2025/09/17/blame/)
+ by D. Ben Knoble on his Junk Drawer personal blog,
+ about the new `git-greb` script that feeds `git grep` to `git blame`
+ (with appropriate options) in order to blame matching lines.
++ [My new git utility `what-changed-twice` needs a new name](https://blog.plover.com/2025/09/21/#what-changed-twice)
+ by Mark Dominus (陶敏修) on his The Universe of Discourse blog,
+ about the tool to help get related changes into the same commit.
++ [Supercharge your Git workflows](https://about.gitlab.com/blog/supercharge-your-git-workflows/)
+ by Darwin Sanoy on GitLab Blog, about how to
+ optimize `git clone` operations in any environment, reducing clone time and disk space,
+ with the [Git Much Faster](https://gitlab.com/gitlab-accelerates-embedded/misc/git-much-faster) script.
+ + Compare with [Scalar](https://github.com/microsoft/scalar),
+ a tool that helps Git scale to handle large Git repositories
+ by enabling some advanced Git features.
+ Scalar was first mentioned in [Git Rev News Edition #60](https://git.github.io/rev_news/2020/02/19/edition-60/),
+ and now is part of Git: [scalar - A tool for managing large Git repositories](https://git-scm.com/docs/scalar).
+ [The Story of Scalar](https://github.blog/2022-10-13-the-story-of-scalar/)
+ was mentioned in [Edition #92](https://git.github.io/rev_news/2022/10/26/edition-92/).
++ [The Origin Story of Merge Queues](https://mergify.com/blog/the-origin-story-of-merge-queues)
+ by Julien Danjou on Mergify Blog.
+ This article traces merge queues history
+ (from Bors and Homu to Bulldozer, Kodiak, Mergify, GitHub and GitLab),
+ why they emerged, and how they became a standard in modern software development.
+ + [Mergify.com](https://mergify.com/),
+ a web service for automating pull requests (free for open-source projects),
+ was mentioned in [Git Rev News Edition #87](https://git.github.io/rev_news/2022/05/26/edition-87/).
++ [Git - Fun Facts](https://dev.to/rubansi/git-fun-fact-45de)
+ by Rubansi Vincent on DEV\.to:
+ a mix of fun and surprising facts about Git.
++ [diff --stat for binary files (in the Jujutsu version control system)](https://neugierig.org/software/blog/2025/08/jj-binary-stat.html)
+ by Evan Martin on neugierig\.org: Tech Notes.
+ + [Jujutsu (`jj`)](https://jj-vcs.github.io/jj/) is a Git-compatible version control system
+ written in Rust, first mentioned in
+ [Git Rev News Edition #85](https://git.github.io/rev_news/2022/03/31/edition-85/).
++ [Jujutsu For Busy Devs, Part 2: "How Do I...?"](https://maddie.wtf/posts/2025-07-21-jujutsu-for-busy-devs/entry/1)
+ by Madeleine Mortensen, continues the [Jujutsu For Busy Devs](https://maddie.wtf/posts/2025-07-21-jujutsu-for-busy-devs)
+ series, mentioned in [Git Rev News Edition #125](https://git.github.io/rev_news/2025/07/31/edition-125/).
++ [Dear GitHub: no YAML anchors, please](https://blog.yossarian.net/2025/09/22/dear-github-no-yaml-anchors)
+ by William Woodruff (yossarian) on his ENOSUCHBLOG blog.
+ He says that they are redundant with existing functionality,
+ make CI/CD human and machine comprehension harder,
+ and their support in GitHub Actions does not introduce any new, previously unavailable features.
++ [Custom VC-Focused Emacs Functions I Created to Enhance My Git Workflow](https://www.rahuljuliato.com/posts/vc-git-functions)
+ by Rahul M. Juliato on Rahul's Blog.
++ [How to delete all squash-merged local git branches with one terminal command](https://whitep4nth3r.com/blog/how-to-delete-all-squash-merged-local-git-branches-with-one-terminal-command/)
+ (which you probably shouldn't use),
+ by Salma Alam-Naylor on her blog.
++ [finding deleted content using git logs](https://kjelsrud.dev/blog/finding-deleted-content-using-git-logs/)
+ by Sindre Kjelsrud, also known as “Sid”, on Sids' blog:
+ a short note on `git log -S`.
++ [Git exclude, a handy feature you might not know about](https://marijkeluttekes.dev/blog/articles/2025/09/03/git-exclude-a-handy-feature-you-might-not-know-about/)
+ by Marijke Luttekes on her blog, about `.git/info/exclude`.
++ [Git Dual Remotes](https://zanshin.net/2025/09/02/git-dual-remotes/):
+ a short note by Mark H. Nichols on his Zanshin.net personal site,
+ about the difference between `git push` and `git fetch` with multiple URLs,
+ and `jj git push --all-remotes`.
++ [Migrating from Gitea to Forgejo the long way](https://msfjarvis.dev/posts/migrating-from-gitea-to-forgejo-the-long-way/)
+ by Harsh Shandilya on his blog.
+ [Gitea](https://about.gitea.com/) and [Forgejo](https://forgejo.org/) are software forges.
++ [Some thoughts on personal git hosting](https://shkspr.mobi/blog/2025/09/some-thoughts-on-personal-git-hosting/)
+ by Terence Eden on Terence Eden’s Blog.
++ [Setting up cgit with Caddy v2 web server](https://www.sixfoisneuf.fr/posts/setting-up-cgit-with-caddy2/)
+ by Simon Garrelou on his SixFoisNeuf blog (2022).
++ [Sourcegraph went dark](https://www.eric-fritz.com/articles/sourcegraph-went-dark/)
+ by Eric Fritz on his blog (2024),
+ about the work that went into ensuring that references are kept alive
+ after the `sourcegraph/sourcegraph` repository went private
+ (there is a public snapshot available at [sourcegraph/sourcegraph-public-snapshot](https://github.com/sourcegraph/sourcegraph-public-snapshot),
+ which is a read-only archived repository).
++ [How to use stacked PRs to unblock your entire team](https://graphite.dev/blog/stacked-prs)
+ by Ninad Pathak on Graphite Blog (2024), and
+ [A guide to using Graphite's stacked PRs for GitHub users](https://dev.to/semgrep/a-guide-to-using-graphites-stacked-prs-for-github-users-5c47)
+ by Martin Jambon for Semgrep on DEV\.to.
+ + See also [Stacked Branches with GitButler](https://blog.gitbutler.com/stacked-branches-with-gitbutler/)
+ by Scott Chacon on the GitButler Blog,
+ mentioned in [Git Rev News Edition #118](https://git.github.io/rev_news/2024/12/31/edition-118/).
+ + See also [Understanding the Stacked Pull Requests Workflow](https://www.git-tower.com/blog/stacked-prs/) by Bruno Brito on Tower's blog,
+ mentioned in [Git Rev News Edition #111](https://git.github.io/rev_news/2024/05/31/edition-111/)
+ together with various other articles and tools about stacked diffs, stacked PRs, and stacked branches.
+ + See also [Rethinking code reviews with stacked PRs](https://www.aviator.co/blog/rethinking-code-reviews-with-stacked-prs/#)
+ by Ankit Jain on the Aviator blog,
+ mentioned in [Git Rev News Edition #115](https://git.github.io/rev_news/2024/09/30/edition-115/)
+ with links to more sites and tools related to stacked PRs, etc.
++ [GitButler's new patch based Code Review (Beta)](https://blog.gitbutler.com/gitbutlers-new-patch-based-code-review)
+ by Scott Chacon on GitButler's Blog.
++ [first-class merges and cover letters](https://dotat.at/@/2025-09-11-cover-letter.html)
+ by Tony Finch on his blog.
+
+
+__Slightly heavier reading__
+
++ [Quo Vadis, Code Review? Exploring the Future of Code Review](https://arxiv.org/abs/2508.06879),
+ a scientific article from August 2025, arXiv:2508.06879
+ (most authors of the paper are from Blekinge Institute of Technology, Karlskrona, Sweden).
++ [Code Review as Decision-Making -- Building a Cognitive Model from the Questions Asked During Code Review](https://arxiv.org/abs/2507.09637),
+ a scientific article from July 2025, arXiv:2507.09637
+ (all authors are from Lund University, Lund, Sweden).
+ Submitted to _Empirical Software Engineering_, Springer Nature.
+
+
+__Easy watching__
+
++ [Git Mini Summit 2025 Videos](https://blog.gitbutler.com/git-mini-summit-2025)
+ by Scott Chacon on GitButler's Blog.
++ Kinetic Merge in action
+ + [Merging through a file split](https://youtu.be/JHb9DKK0LIA)
+ + [Complex merge demonstration](https://youtu.be/6jry6NKxGJA)
+ + [Merging code embedded inside an if-statement](https://www.youtube.com/watch?v=sm4Naq_zJU0&t=2s)
++ [12 Git commands visualized in 3D: a spatial approach to understanding version control](https://www.youtube.com/watch?v=C2aFC8wFp2A)
+ [4:58], on the Initial Commit channel on YouTube.
++ [Stacked Branches With Lazygit](https://www.youtube.com/watch?v=M6S-9Y8peDY)
+ [12:18] by Jesse Duffield (Lazygit author) on YouTube.
+ + [lazygit](https://github.com/jesseduffield/lazygit) is a simple [windowed] terminal UI for Git,
+ written in Go. It was first mentioned in [Git Rev News Edition #42](https://git.github.io/rev_news/2018/08/22/edition-42/).
+
+
+__Git tools and sites__
+
++ [Kinetic Merge](https://github.com/sageserpent-open/kineticMerge)
+ is a command-line tool that helps you merge a heavily refactored codebase and stay sane.
+ Its goals are to:
+ + Merge two branches of a Git repository *holistically across the entire codebase*.
+ + Take into account the motion of code in either branch due to refactoring.
+ + Handle file renames, file splits, file concatenation.
+ + Handle code being excised from one place in a file and moved elsewhere in that file or to somewhere within another file, or hived off all by itself in its own new file.
+ + Work alongside the usual Git workflows, allowing ordinary Git merge to take over at the end if necessary.
+ + Be a simple command line tool that tries to do as much as it can without supervision, and with minimal supervision when complexities are encountered.
+
+ Written in Scala, under an MIT license.
++ [Git Much Faster](https://gitlab.com/gitlab-accelerates-embedded/misc/git-much-faster)
+ is a comprehensive benchmarking tool for comparing different Git clone strategies,
+ especially for large repositories.
+ Written as a Bash shell script, under MIT license.
++ [_prek_](https://prek.j178.dev/) is a reimagined version of [pre-commit](https://pre-commit.com/), built in Rust.
+ It is a framework to run hooks written in many languages,
+ and it manages the language toolchain and dependencies for running the hooks.
+ prek is not production-ready yet: some subcommands and languages are not implemented.
+ Under MIT license.
+ + See also [Ready prek go!](https://hugovk.dev/blog/2025/ready-prek-go/)
+ article by Hugo van Kemenade on his blog.
++ [git-sqlite](https://github.com/cannadayr/git-sqlite)
+ is a collection of shell scripts,
+ including a custom diff and merge driver for SQLite,
+ that allows a SQLite database to be tracked using the Git version control system.
+ Under MIT license.
+
++ [LearnGit.io](https://learngit.io/) teaches version control
+ using animated visualizations of Git internals—and is
+ [now free](https://learngit.io/posts/learngit-io-is-now-free-for-students) for students and teachers.
+ Created by Jack Lot of [The Modern Coder](https://www.youtube.com/@themoderncoder) YouTube channel,
+ LearnGit offers 41 video lessons across 11 modules, along with quizzes,
+ a Git command search, and high-quality written documentation.
+ Educators can email jack@learngit.io for bulk vouchers.
+ First mentioned in [Git Rev News Edition #108](https://git.github.io/rev_news/2024/02/29/edition-108/).
++ [GitFichas](https://gitfichas.com/en) (also know as GitStudyCards)
+ is a collection of study cards about Git,
+ for devs that might need a refresher about Git commands.
+ GitFichas is now [open-source](https://github.com/jtemporal/gitfichas)
+ and undergoing some construction.
++ Git's home page now has a [Learn](https://git-scm.com/learn) section, including [a handy Git Cheat Sheet](https://git-scm.com/cheat-sheet), contributed by the ever-industrious
+ [Julia Evans](https://jvns.ca/). These contributions are part of [the initiative to refresh the look and contents of git-scm.com](https://github.com/git/git-scm.com/issues/2046).
+
+
+## Releases
+
++ Git for Windows [v2.51.0(2)](https://github.com/git-for-windows/git/releases/tag/v2.51.0.windows.2)
++ Gerrit Code Review [3.13.0-rc0](https://www.gerritcodereview.com/3.13.html#3130)
++ Bitbucket Data Center [10.0](https://confluence.atlassian.com/bitbucketserver/release-notes-872139866.html)
++ GitHub Enterprise [3.17.6](https://docs.github.com/enterprise-server@3.17/admin/release-notes#3.17.6),
+[3.16.9](https://docs.github.com/enterprise-server@3.16/admin/release-notes#3.16.9),
+[3.15.13](https://docs.github.com/enterprise-server@3.15/admin/release-notes#3.15.13),
+[3.14.18](https://docs.github.com/enterprise-server@3.14/admin/release-notes#3.14.18)
++ GitLab [18.4.1, 18.3.3, 18.2.7](https://about.gitlab.com/releases/2025/09/25/patch-release-gitlab-18-4-1-released/),
+[18.4](https://about.gitlab.com/releases/2025/09/18/gitlab-18-4-released/),
+[18.3.2, 18.2.6, 18.1.6](https://about.gitlab.com/releases/2025/09/10/patch-release-gitlab-18-3-2-released/)
++ GitKraken [11.4.0](https://help.gitkraken.com/gitkraken-desktop/current/)
++ Sourcetree [4.2.14](https://product-downloads.atlassian.com/software/sourcetree/ReleaseNotes/Sourcetree_4.2.14.html)
++ tig [2.6.0](https://github.com/jonas/tig/releases/tag/tig-2.6.0)
++ Garden [2.3.0](https://github.com/garden-rs/garden/releases/tag/v2.3.0)
++ Git Cola [4.15.0](https://github.com/git-cola/git-cola/releases/tag/v4.15.0)
++ GitButler [0.16.8](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.16.8),
+[0.16.7](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.16.7)
++ Kinetic Merge [1.9.0](https://github.com/sageserpent-open/kineticMerge/releases/tag/v1.9.0)
++ git-credential-oauth [0.16.0](https://github.com/hickford/git-credential-oauth/releases/tag/v0.16.0)
++ Tower for Mac [14.4, 14.5](https://www.git-tower.com/release-notes/mac)
++ git-flow-next [0.1](https://git-flow.sh/)
+
+
+## Credits
+
+This edition of Git Rev News was curated by
+Christian Couder <>,
+Jakub Narębski <>,
+Markus Jansen <> and
+Kaartic Sivaraam <>
+with help from Toon Claes, Johannes Schindelin,
+Bruno Brito, Gerard Murphy, Jack Lot, Ben Knoble
+and Štěpán Němec.
diff --git a/_posts/2025-10-31-edition-128.markdown b/_posts/2025-10-31-edition-128.markdown
new file mode 100644
index 000000000..40be28f55
--- /dev/null
+++ b/_posts/2025-10-31-edition-128.markdown
@@ -0,0 +1,549 @@
+---
+title: Git Rev News Edition 128 (October 31st, 2025)
+layout: default
+date: 2025-10-31 12:06:51 +0100
+author: chriscool
+categories: [news]
+navbar: false
+---
+
+## Git Rev News: Edition 128 (October 31st, 2025)
+
+Welcome to the 128th 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](http://git.github.io).
+
+This edition covers what happened during the months of September and October 2025.
+
+## Discussions
+
+### General
+
+* [Git participated in GSoC (Google Summer of Code) 2025](https://summerofcode.withgoogle.com/programs/2025/organizations/git)
+
+ All the contributors have successfully passed their final evaluation
+ and published a final report:
+
+ - Lucas Oshiro [worked](https://lucasoshiro.github.io/gsoc-en/#weeks) on the
+ [Machine-Readable Repository Information Query Tool](https://summerofcode.withgoogle.com/programs/2025/projects/fGgMYHwl)
+ project. He was mentored by Patrick Steinhardt and Karthik Nayak. The final
+ report can be found on
+ [his website](https://lucasoshiro.github.io/gsoc-en/#final-report).
+
+ - Meet Soni [worked](https://inosmeet.github.io/posts/gsoc25/) on the
+ [Consolidate ref-related functionality into git-refs](https://summerofcode.withgoogle.com/programs/2025/projects/xVrT5e2q)
+ project. He was mentored by Patrick Steinhardt and Jialuo She. The final
+ report can be found on
+ [his website](https://inosmeet.github.io/posts/gsoc25/gsoc25_final/).
+
+ - Ayush Chandekar [worked](https://ayu-ch.github.io/) on the
+ [Refactoring in order to reduce Git’s global state](https://summerofcode.withgoogle.com/programs/2025/projects/no7dVMeG)
+ project. He was mentored by Christian Couder and Ghanshyam Thakkar. The final
+ report can be found on
+ [his website](https://ayu-ch.github.io/2025/08/29/gsoc-final-report.html).
+
+ Kaartic Sivaraam and Christian Couder were
+ ["org admins"](https://developers.google.com/open-source/gsoc/help/oa-tips).
+
+ Congratulations to the contributors, their mentors and the org admins!
+
+* [Git Merge 2025 conference](https://git-merge.com/) and [Contributor's Summit 2025](https://lore.kernel.org/git/aOQVeVYY6zadPjln@nand.local/)
+
+ The Git Merge conference happened on
+ [September 29th and 30th](https://github.blog/open-source/git/20-years-of-git-2-days-at-github-hq-git-merge-2025-highlights/)
+ in San Francisco, hosted by [GitHub](https://github.com/) at their
+ GitHub HQ. The [session records](https://www.youtube.com/playlist?list=PLNXkW_le40U6Ms1XlsYKi_yUh5J2FOSlf)
+ are available.
+
+ On the second day, there was also
+ [the Contributor's Summit](https://lore.kernel.org/git/aOQVeVYY6zadPjln@nand.local/).
+ The [full notes](https://docs.google.com/document/d/1arvvXP8DrF3F8PCKQOmGvYh5jUg8P9Clx9m-FgDD4EI/)
+ as well as [notes broken down by topic](https://lore.kernel.org/git/aOQV6iM49QDhcC+C@nand.local/#r)
+ are available.
+
+* [Git Mini Summit 2025](https://lore.kernel.org/git/aGwHt9HCd86hVuKh@pks.im/)
+
+ On August 28 in Amsterdam, a [Git Mini Summit](https://lore.kernel.org/git/aGwHt9HCd86hVuKh@pks.im/)
+ happened as
+ [a co-hosted event of the Open Source Summit Europe](https://osseu2025.sched.com/event/28R2Q/git-mini-summit-additional-fee-pre-registration-required),
+ sponsored by GerritForge, GitButler, GitLab, and Google.
+ The [schedule](https://drive.google.com/file/d/1vacimnS9NUTcYUsRe8100El8Hdl_C7GD/view)
+ and [session records](https://blog.gitbutler.com/git-mini-summit-2025)
+ are available.
+
+
+
+
+### Support
+
++ [[Change] Git build issue on NonStop](https://lore.kernel.org/git/01c101dc2842$38903640$a9b0a2c0$@nexbridge.com/)
+
+ Randall S. Becker reported on the mailing list that CI tests on the
+ NonStop x86 platform were broken after the `uintptr_t` type started
+ to be used in [clar](https://github.com/clar-test/clar) tests when
+ displaying error messages in test failures (in case pointer comparisons
+ fail).
+
+ Jeff King, alias Peff, replied to Randall that `uintptr_t` was
+ already used in many places in the regular code, and guessed the
+ issue might come from how clar defined that type. He noted though
+ that the line in the clar test where `uintptr_t` appeared also
+ contained `PRIxPTR` which is a macro that is not used in the regular
+ code. So he wondered if just replacing that macro with `PRIuMAX`
+ (which is often used) would be enough to fix the issue.
+
+ `PRIxPTR`, `PRIuMAX` and similar macros are format specifier macros
+ from the C standard library (defined in ``) that provide
+ portable ways to print integer types using functions like `printf()`
+ across different platforms. They are all named in the same way, with
+ `PRI` meaning `printf`, the next letter indicating the format, like
+ `x` for hexadecimal and `u` for unsigned decimal, and the last part
+ indicating the type, like `PTR` for pointer-sized integers, `MAX`
+ for maximum-width integers, `64` for 64-bit, etc.
+
+ Randall replied to Peff that replacing `PRIxPTR` with `PRIuMAX`
+ would work, and that he was going to try it.
+
+ Patrick Steinhardt also replied to Randall and Peff saying it would
+ work, and asked Peff if he wanted to send that change.
+
+ Peff replied to Patrick that he'd be happy if Patrick sent the
+ change, but noted that using `PRIxMAX` might be better than
+ `PRIuMAX` as the code wanted to print hexadecimal values.
+
+ Patrick then reported to Peff that Peff's suggestion to use the
+ `PRIxMAX` or `PRIuMAX` format specifier macros didn't work on 32 bit
+ systems, because casting a pointer to an integer of different size
+ (the pointer is 32 bits, but `uintmax_t` is 64 bits) fails.
+
+ Patrick proposed using `%p` as a format specifier saying it might be
+ a better trade-off. The downside was that the output format would be
+ unpredictable across platforms as `%p` doesn't have a standardized
+ output format. So tests that validated the exact error message
+ format would have to be dropped. But at least `%p` would work
+ everywhere and produce stable output.
+
+ Junio Hamano, the Git maintainer, agreed with Patrick that `%p` was
+ "the most appropriate solution".
+
+ Randall then confirmed that `%p` worked on NonStop x86 even if the
+ man pages warned to the contrary.
+
+ The `%p` solution was eventually merged to the 'master' branch.
+
+
+## Developer Spotlight: Kristoffer Haugsbakk
+
+* **Who are you and what do you do?**
+
+ I’m Kristoffer from Norway. My day job is working on a Java webapp
+ primarily used for clinical mental health questionnaires.
+
+* **What would you name your most important contribution to Git?**
+
+ One I like was when I and the mailing list collaborators fixed a bug
+ related to Git notes handling by [git-format-patch(1)][1]. It’s
+ small and niche but Git notes handling is very important to me; I
+ think Notes are a great way to maintain metadata between patch
+ submissions. In fact I think it’s great for most commit metadata
+ that I am interested in maintaining.
+
+[1]: https://git-scm.com/docs/git-format-patch
+
+* **What are you doing on the Git project these days, and why?**
+
+ The one I am focusing on is improving the [git-patch-id(1)][2]
+ documentation. It so happens that you can use that command to make a
+ commit—patch-id mapping for the whole repository, which you then in
+ turn can use to make an improved [git-cherry(1)][3] oneliner (one
+ that says what the upstream commit hash is) as well as, say, using
+ commands like git-range-diff to see if the upstream committer made
+ any changes to your submission like fixing commit message typos. But
+ most uses of this command that I see just use it to figure out what
+ the patch ID of one single commit is and have to script everything
+ around that, like loop over [git-rev-list(1)][4].
+
+[2]: https://git-scm.com/docs/git-patch-id
+[3]: https://git-scm.com/docs/git-cherry
+[4]: https://git-scm.com/docs/git-rev-list
+
+* **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?**
+
+ I would ask them to find a way for projects to define their own
+ conventions and preferences that can be easily shared with all
+ contributors. Something better than asking each contributor to
+ download and install hooks. Projects need a better and more
+ declarative way to configure how their project is supposed to
+ work. One example might be that a project does not want merge
+ commits to land in the mainline. It should be simple to take that
+ high-level goal and make sure that the in-effect central repository
+ never gets any merge commits.
+
+ Git will not be replaced any time soon, despite it being more
+ difficult to use than it ought to be. But we can already see what
+ the effects of the high difficulty of using it is: some projects
+ outsource all commit messages to issue trackers, and change
+ proposals (pull requests and patch series descriptions) to webapp
+ forges. (Meaning they don’t even duplicate the PR description
+ somewhere in Git like in a commit message.) What you end up with is
+ still Git but with all the interesting information living at least
+ one hyperlink away.
+
+* **If you could remove something from Git without worrying about
+ backwards compatibility, what would it be?**
+
+ I can’t think of a single thing to remove that would have a big
+ impact.
+
+ I guess I would remove [git-filter-branch(1)][5]. People can use
+ [git-filter-repo(1)][6]. And with that one removed I wouldn’t have to ask
+ people to not use it any more. ;)
+
+[5]: https://git-scm.com/docs/git-filter-branch
+[6]: https://github.com/newren/git-filter-repo
+
+* **Documentation contributions require understanding both the technical
+ implementation and the user perspective. How do you approach
+ bridging that gap? Do you have strategies for ensuring documentation
+ stays accurate as code evolves?**
+
+ Most of the challenge in bridging the gap for me is about trying to
+ describe things accurately while not being tedious and verbose. The
+ worst challenge is when I realistically have one paragraph to
+ explain something but there are eight factors to mention. (Not a
+ real case; just the feeling of a challenge that I have encountered
+ before.)
+
+ For things that are either just difficult or have many factors to
+ consider I think the best approach we have right now is to mention
+ other documentation pages in parentheses. An obvious candidate is
+ [gitglossary(7)][7] where we can gather all kinds of jargon and be
+ as verbose as we want to. :)
+
+ I don’t have any strategies for ensuring that documentation stays
+ accurate as code evolves. Let’s take something concrete as an
+ example: an update to the documentation adds a very similar
+ paragraph to two documentation pages. That is an obvious maintenance
+ burden since a later update is likely to necessitate a change in
+ both places, but you are likely to only deal with one of them. The
+ obvious fix is to parameterize the paragraph. But I don’t have good
+ indirect experience with that in [AsciiDoc][8]; the last time I saw
+ something parameterized was when an [AsciiDoc][8] macro forced
+ inline formatting to be handled literally. The cure seems worse than
+ the disease to me.
+
+ The best I can do now when making updates is to investigate the
+ lines that I am changing and find the histories of any possible
+ near-duplicate texts.
+
+[7]: https://git-scm.com/docs/gitglossary
+[8]: https://asciidoc.org/
+
+* **What is your favorite Git-related tool/library, outside of Git
+ itself?**
+
+ [Magit][9]. An Emacs Git frontend.
+
+[9]: https://magit.vc/
+
+* **Do you happen to have any memorable experience w.r.t. contributing
+ to the Git project? If yes, could you share it with us?**
+
+ When I added a test case to `t/t7001-mv.sh` that [made the continuous
+ build routine on Windows (CI) time out][16]. The test was
+ `test_expect_failure` and triggered a C assertion, and the Windows
+ CI pops up a modal dialog on assertion failures. That dialog is of
+ course never dismissed by any operator and so the suite eventually
+ timed out.
+
+[16]: https://lore.kernel.org/git/pull.1908.git.1745593515875.gitgitgadget@gmail.com/
+
+* **What is your toolbox for interacting with the mailing list and for
+ development of Git?**
+
+ I use the builtin commands for making patches and sending them
+ ([git-format-patch(1)][10] and [git-send-email(1)][11]). For programming and
+ writing I use the basic, needed tools along with Emacs. Very
+ occasionally I will use GDB.
+
+[10]: https://git-scm.com/docs/git-format-patch
+[11]: https://git-scm.com/docs/git-send-email
+
+* **What is your advice for people who want to start Git development?
+ Where and how should they start?**
+
+ Find something technically wrong in the documentation and fix
+ it. That’s what I did in 2016; I wanted to test out this new (to me)
+ “email-based workflow”. Focus on fixing things instead of
+ subjectively improving something. Because someone might object and
+ propose that you send a new version. Making subjective documentation
+ improvements is the next step in terms of difficulty I guess.
+
+ It sounds trivial but someone used to Git forges will have enough
+ challenges just sending proper patches to the project over email.
+
+ Also read through [`Documentation/SubmittingPatches`][12]. I don’t
+ really see many corrections that refer to other documents. You could
+ of course get a correction that refers to some [*lore*][13] but that
+ is unlikely to happen for simple changes if you just structure it
+ similar to recent, accepted submissions that you find.
+
+[12]: https://git-scm.com/docs/SubmittingPatches
+[13]: https://lore.kernel.org/git
+
+* **If there's one tip you would like to share with other Git
+ developers, what would it be?**
+
+ You won’t get any C programming tips from me since I can’t write or
+ edit three lines of C code without segfaulting five times.
+
+ Take advantage of the fact that the Git history is so
+ well-structured. Maybe you find some questionable behavior or
+ code. Use the “pickaxe” technique (see [git-log(1)][14]) on some
+ good candidate text and trace the behavior back to the start. Maybe
+ the commit message explains the issue or behavior. If not use
+ `refs/notes/amlog` (which you should be “subscribed” to already) and
+ see if something relevant was discussed on the patch discussion. If
+ not there is likely to be no written record out there; another thing
+ that this project is disciplined about is keeping the relevant
+ discussion on the mailing list, not the mailing list and N other
+ satellite fora.
+
+ Those links (to commits and archived emails) are very valuable when
+ you want to discuss a change to something that has been in
+ [git(1)][15] for years and years.
+
+[14]: https://git-scm.com/docs/git-log#Documentation/git-log.txt--Gregex
+[15]: https://git-scm.com/docs/git
+
+## Other News
+
+__Various__
+
++ [Git considers SHA-256, Rust, LLMs, and more](https://lwn.net/Articles/1042172/)
+ by Jonathan Corbet on LWN\.net.
++ [Git Developers Talk About Potentially Releasing Git 3.0 By The End Of Next Year](https://www.phoronix.com/news/Git-3.0-Release-Talk-2026)
+ by Michael Larabel on Phoronix.
++ [GitHub is migrating to Azure! And goodbye to new development for a year.](https://www.redhotcyber.com/en/post/github-is-migrating-to-azure-and-goodbye-to-new-development-for-a-year/)
+ by Redazione RHC on Red Hot Cyber.
++ [Fedora Moves Towards Forgejo](https://fedoramagazine.org/fedora-moves-towards-forgejo-a-unified-decision/)
+ by Matthew Miller and Akashdeep Dhar on December 4, 2024
+ in Fedora Magazine.
+ + [Forgejo](https://forgejo.org/) is a self-hosted lightweight software forge,
+ written in Go; nowadays a hard fork of Gitea (which in turn was based on Gogs).
+ It was first mentioned in passing in [Git Rev News Edition #103](https://git.github.io/rev_news/2023/09/30/edition-103/).
+
+
+__Light reading__
+
++ [Building for the future: on Tangled's existence and direction](https://anirudh.fi/future)
+ by Anirudh Oppiliappan on their blog;
+ also published [at icy takes blog](https://icy.leaflet.pub/3m47cll72hs25) on ATProto.
+ + [Tangled.sh](https://blog.tangled.sh/intro) is a new social-enabled Git collaboration platform
+ built on top of the AT Protocol / ATProto
+ (which is behind the [BlueSky](https://bsky.app/) microblogging federated social media service).
+ It was first mentioned in [Git Rev News Edition #125](https://git.github.io/rev_news/2025/07/31/edition-125/).
++ [6 months of Tangled: a quick recap, and notes on the future](https://blog.tangled.org/6-months)
+ by Anirudh Oppiliappan and Akshay Oppiliappan on Tangled Blog.
++ [Socially self-hosting source code with Tangled on Bluesky](https://anil.recoil.org/notes/disentangling-git-with-bluesky)
+ by Anil Madhavapeddy, Professor of Planetary Computing, on his blog.
++ [Redistributing Git with Nostr](https://fiatjaf.com/18ff5416.html)
+ by início on their blog.
+ + There exists [gitstr (`git str`)](https://github.com/fiatjaf/gitstr),
+ which is a tool to send and receive Git patches
+ over [Nostr](https://nostr.com/), using [NIP-34](https://github.com/nostr-protocol/nips/pull/997)
+ (first mentioned in [Git Rev News Edition #109](https://git.github.io/rev_news/2024/03/31/edition-109/)).
+ + Note that [git-credential-oauth](https://github.com/hickford/git-credential-oauth),
+ a Git credential helper that securely authenticates to GitHub, GitLab, BitBucket and Gerrit
+ using [OAuth](https://datatracker.ietf.org/wg/oauth/about/),
+ can replace the "create an account; pick a password; confirm an email address; set up SSH keys for pushing" steps.
++ [How GitHub won software development](https://www.infoworld.com/article/4069045/how-github-won-software-development.html)
+ by Nick Hodges on Rubber Duck Reflections opinions blog on InfoWorld.
++ [You already have a git server](https://maurycyz.com/misc/easy_git/)
+ on Maurycy's blog;
+ describes how one can serve Git repositories via SSH (with SSH access)
+ or via dumb HTTP (with a web server).
++ [Simple automated deployments using git push](https://garrido.io/notes/simple-automated-deployments-git-push/)
+ by Gabriel Garrido on his blogs / notes (2024).
++ [Discussion of the Benefits and Drawbacks of the Git Pre-Commit Hook](https://yeldirium.de/2025/10/09/pre-commit-hooks/index.html)
+ by Hannes Leutloff on his blog.
++ [You can use `fzf` to review git commits](https://jvns.ca/til/fzf-preview-git-commits/)
+ by Julia Evans in her TIL (Today I've Learned) section.
+ + See also [Improving shell workflows with fzf](https://seb.jambor.dev/posts/improving-shell-workflows-with-fzf/),
+ mentioned in [Git Rev News Edition #74](https://git.github.io/rev_news/2021/04/30/edition-74/), and
+ [Curing A Case Of Git-UX](https://oppi.li/posts/curing_a_case_of_git-UX/),
+ mentioned in [Git Rev News Edition #126](https://git.github.io/rev_news/2025/08/31/edition-126/).
++ [Switch to Jujutsu already: a tutorial](https://www.stavros.io/posts/switch-to-jujutsu-already-a-tutorial/)
+ by Stavros on Stavros' Stuff.
+ + [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 Is Amazing!](https://heiwiper.com/posts/magit-is-awesome/)
+ by Abdallah Maouche (heiwiper) on his blog
+ (how it does things that others need to use Jujutsu over Git for).
+ + [Magit](https://magit.vc/) is a popular [Emacs](https://www.gnu.org/software/emacs) editor interface to Git,
+ first mentioned (in passing) in [Git Rev News Edition #6](https://git.github.io/rev_news/2015/08/05/edition-6/).
++ [Branching in a Sapling Monorepo](https://engineering.fb.com/2025/10/16/developer-tools/branching-in-a-sapling-monorepo/)
+ + [Sapling](https://sapling-scm.com/) is a scalable, user-friendly, and open-source source control system
+ that powers Meta's (Facebook's) monorepo.
+ It was first mentioned in [Git Rev News Edition #93](https://git.github.io/rev_news/2022/11/30/edition-93/).
++ [Stop Rebasing Everything: Your Git History Isn’t That Special](https://dev.to/dolig/stop-rebasing-everything-your-git-history-isnt-that-special-ln3),
+ an argument in the merge-vs-rebase debate.
+ by Guillaume on DEV\.to.
++ [Diff Algorithms](https://flo.znkr.io/diff/)
+ by Florian Zenker on his website.
+ The result of this exploration was [znkr.io/diff](https://znkr.io/diff),
+ a difference algorithm module for Go.
+ + Note that with [`git diff`](https://git-scm.com/docs/git-diff)
+ you can choose between `myers` (default), `minimal`, `patience` and `histogram` algorithms.
++ [Git Super-Power: The Three-Way Merge](https://qsantos.fr/2024/05/01/git-super-power-the-three-way-merge/)
+ by Quentin Santos on his blog (2024).
+ Provides the following tl;dr: `git config --global merge.conflictstyle diff3`.
++ [Anyone Can Commit Code as You on GitHub (Here's How to Stop Them)](https://www.nickyt.co/blog/anyone-can-commit-code-as-you-on-github-heres-how-to-stop-them-2in7/)
+ with signed commits (with tutorial focusing on macOS using GPG Keychain).
+ Written by Nick Taylor on his Just Some Dev blog.
++ [GitHub Ensloppification](https://dbushell.com/2025/08/11/github-ensloppification/)
+ by David Bushell on his blog.
++ ["GitHub" Is Starting to Feel Like Legacy Software](https://www.mistys-internet.website/blog/blog/2024/07/12/github-is-starting-to-feel-like-legacy-software/)
+ rant by Misty De Méo on her blog (2024).
++ [Implementing Conventional Commits with Jira Ticket Prefix Validation](https://heristop.github.io/blog/2024-07-09-conventional-commit-jira/)
+ by Alexandre Mogère (heristop) on Zazen Code.
+ + The [Conventional Commits](https://www.conventionalcommits.org/) specification
+ was first mentioned in [Git Rev News Edition #52](https://git.github.io/rev_news/2019/06/28/edition-52/),
+ and in many editions since.
++ [Conventional Commits considered harmful](https://larr.net/p/cc.html)
+ (or rather overly strict enforcement of the standard),
+ rant by Salih Muhammed, with a few further links.
++ [Contribute to GitFichas](https://jtemporal.com/contribute-to-gitfichas/)
+ by Jessica Temporal on her blog.
+ + [GitFichas](https://gitfichas.com/en) (also know as GitStudyCards)
+ is a collection of study cards about Git,
+ for devs that might need a refresher about Git commands.
+ Mentioned in [the previous edition of Git Rev News](https://git.github.io/rev_news/2025/09/30/edition-127/).
+
+
+__Easy watching__
+
++ [Gerrit User Summit 2025, featuring also GitButler and Jujutsu](https://www.youtube.com/playlist?list=PLySCWiWz9cNuiJK2Uy3foHGvkxL3fBLUC)
+ by Luca Milanesio on GerritForge's YouTube channel.
++ [Jujutsu at Google](https://www.youtube.com/watch?v=v9Ob5yPpC0A&list=PLOU2XLYxmsILM5cRwAK6yKdtKnCK6Y4Oh&index=8)
+ ([slides](https://drive.google.com/file/d/1dVzug1lHoOxdbFu8gcCJCu-G_uVMUATI/edit))
+ on Google for Developers channel on YouTube;
+ part of [JJ Con 2025 playlist](https://www.youtube.com/playlist?list=PLOU2XLYxmsILM5cRwAK6yKdtKnCK6Y4Oh).
+ In this talk, Martin von Zweigbergk presents
+ on Jujutsu architecture and future plans.
+ JJ Con 2025 was a dedicated conference hosted by Google
+ for the [Jujutsu](https://jj-vcs.github.io/jj/latest/) version control system.
++ [Solving Git's Pain Points with Jujutsu (with Martin von Zweigbergk)](https://www.youtube.com/watch?v=ulJ_Pw8qqsE)
+ on Developer Voices channel on YouTube.
+
+
+__Scientific papers__
+
++ Ya-Nan Li, Yaqing Song, Qiang Tang, Moti Yung:
+ _"End-to-End Encrypted Git Services"_,
+ Cryptology {ePrint} Archive, Paper 2025/1208,
+ ,
+ DOI:10.1145/3719027.3744815
+ + See [_"Scientists develop end-to-end encryption for git services"_](https://techxplore.com/news/2025-10-scientists-encryption-git.html)
+ article by University of Sydney, edited by Stephanie Baum, reviewed by Robert Egan,
+ on TechXplore.
++ S.R.P. van Hal, M. Post, K. Wendel:
+ _"Generating Commit Messages from Git Diffs"_,
+ [arXiv:1911.11690](https://arxiv.org/abs/1911.11690) (2019)
+ mentions "inherent shortcoming of current commit message generation models,
+ which perform well by memorizing certain constructs."
+
+
+__Git tools and sites__
+
++ [diff-modulo-base](https://git.sr.ht/~nhaehnle/diff-modulo-base)
+ is a tool that allows you to compare the relevant changes
+ of two versions of a rebased branch given three input diffs:
+ two _base_ diffs that show the changes since the respective merge bases
+ and a _target_ diff between the branches you are actually interested in.
+
+ It is very similar to (and actually builds on) `git range-diff`,
+ but differs in resulting output.
+ Written in Rust, under MIT License.
++ [Worktree Manager](https://github.com/jarredkenny/worktree-manager) (wtm)
+ is a fast, modern CLI tool for managing Git worktrees in bare repositories.
+ Written in TypeScript for Bun, under MIT License.
++ [git-metrics](https://github.com/jdrouet/git-metrics)
+ is a Git extension that makes it possible to track metrics about your project,
+ which are stored within the git repository (using `git notes`).
+ Written in Rust, under MIT License.
+ Described in [Build metrics and budgets with git-metrics](https://dev.to/jdrouet/build-metrics-and-budgets-with-git-metrics-4pb4)
+ article by Jérémie Drouet on DEV\.to (2024).
+ + There is another [git-metrics](https://github.com/Praqma/git-metrics) tool,
+ by the Praqma / Eficode DevOps company,
+ which consists of a set of scripts to analyse a Git repository for metrics
+ such as lead time and open branches. Written in Python, no license provided.
+ It was mentioned in passing in [Git Rev News Edition #48](https://git.github.io/rev_news/2019/02/27/edition-48/).
++ [git-spice](https://abhinav.github.io/git-spice/) is a tool for stacking Git branches.
+ It lets you manage and navigate stacks of branches, conveniently modify and rebase them,
+ and create GitHub Pull Requests or GitLab Merge Requests from them.
+ Written in Go, under GPL 3.0 License.
+ + A _stacked branch_ refers to a set of branches that build upon each other in a linear sequence.
+ Stacked branches or stacked diffs were first mentioned in [Git Rev News #44](https://git.github.io/rev_news/2018/10/24/edition-44/),
+ and most recently in [Git Rev News #127](https://git.github.io/rev_news/2025/09/30/edition-127/),
+ where you can find even more links about this technique.
++ [Git Granary](https://git.dbushell.com/dbushell/granary)
+ is a [Git Large File Storage](https://git-lfs.com/) (LFS)
+ server implementation written in TypeScript. Under MIT License.
+ Git Granary was designed for self-hosted personal use.
+ See [Git Granary](https://dbushell.com/2024/07/25/git-granary/)
+ blog post by David Bushell on his blog (2024).
++ [gibr](https://github.com/ytreister/gibr) is a Git CLI tool
+ for intelligently creating branch names.
+ It connects your Git workflow to your issue tracker for that purpose;
+ currently supporting GitHub, GitLab, Jira, and Linear
+ (with Monday\.com support planned).
+ Written in Python, under MIT License.
++ [0github.com](https://0github.com/)
+ is a service offering a heatmap diff viewer for code reviews,
+ color-coding every diff line/token by how much human attention it probably needs.
+ To try it, replace github.com with 0github.com in any GitHub pull request URL.
+ The [cmux](https://cmux.dev/) engine it uses is open source (MIT License).
+ It uses a LLM (Large Language Model) to perform this task.
+
+
+## Releases
+
++ Git [2.51.2](https://lore.kernel.org/git/xmqqo6psjq2n.fsf@gitster.g/),
+[2.51.1](https://lore.kernel.org/git/xmqqa51suhh5.fsf@gitster.g/)
++ Git for Windows [v2.51.2(1)](https://github.com/git-for-windows/git/releases/tag/v2.51.2.windows.1),
+[v2.51.1(1)](https://github.com/git-for-windows/git/releases/tag/v2.51.1.windows.1),
+[v2.51.0(2)](https://github.com/git-for-windows/git/releases/tag/v2.51.0.windows.2)
++ GitHub Enterprise [3.18.0](https://docs.github.com/enterprise-server@3.18/admin/release-notes#3.18.0)
++ GitLab [18.5.1, 18.4.3, 18.3.5](https://about.gitlab.com/releases/2025/10/22/patch-release-gitlab-18-5-1-released/),
+[18.5](https://about.gitlab.com/releases/2025/10/16/gitlab-18-5-released/),
+[18.4.2, 18.3.4, 18.2.8](https://about.gitlab.com/releases/2025/10/08/patch-release-gitlab-18-4-2-released/)
++ Gerrit Code Review [3.10.9](https://www.gerritcodereview.com/3.10.html#3109),
+[3.13.0-rc0](https://www.gerritcodereview.com/3.13.html#3130),
+[3.13.0-rc1](https://www.gerritcodereview.com/3.13.html#3130),
+[3.13.0-rc2](https://www.gerritcodereview.com/3.13.html#3130),
+[3.13.0-rc3](https://www.gerritcodereview.com/3.13.html#3130),
+[3.13.0-rc4](https://www.gerritcodereview.com/3.13.html#3130),
+[3.13.0-rc5](https://www.gerritcodereview.com/3.13.html#3130)
++ GitKraken [11.5.1](https://help.gitkraken.com/gitkraken-desktop/current/),
+[11.5.0](https://help.gitkraken.com/gitkraken-desktop/current/)
++ GitHub Desktop [3.5.3](https://desktop.github.com/release-notes/)
++ Git Cola [4.16.0](https://github.com/git-cola/git-cola/releases/tag/v4.16.0)
++ GitButler [0.16.10](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.16.10),
+[0.16.9](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.16.9)
++ Kinetic Merge [1.10.0](https://github.com/sageserpent-open/kineticMerge/releases/tag/v1.10.0),
+[1.9.1](https://github.com/sageserpent-open/kineticMerge/releases/tag/v1.9.1)
+
+## Credits
+
+This edition of Git Rev News was curated by
+Christian Couder <>,
+Jakub Narębski <>,
+Markus Jansen <> and
+Kaartic Sivaraam <>
+with help from Kristoffer Haugsbakk, Lee Reilly,
+Luca Milanesio and Štěpán Němec.
diff --git a/rev_news/drafts/edition-125.md b/rev_news/drafts/edition-125.md
deleted file mode 100644
index cff129335..000000000
--- a/rev_news/drafts/edition-125.md
+++ /dev/null
@@ -1,62 +0,0 @@
----
-title: Git Rev News Edition 125 (July 31st, 2025)
-layout: default
-date: 2025-07-31 12:06:51 +0100
-author: chriscool
-categories: [news]
-navbar: false
----
-
-## Git Rev News: Edition 125 (July 31st, 2025)
-
-Welcome to the 125th 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](http://git.github.io).
-
-This edition covers what happened during the months of June 2025 and July 2025.
-
-## Discussions
-
-
-
-
-
-
-
-
-
-## Other News
-
-__Various__
-
-
-__Light reading__
-
-
-
-__Git tools and sites__
-
-- [git-phoenix](https://github.com/yaitskov/git-phoenix) does repository recovery.
-
-## Releases
-- Tower for Mac [13.1](https://www.git-tower.com/release-notes/mac?show_tab=release-notes)
-- Tower for Windows [9.1](https://www.git-tower.com/release-notes/windows?show_tab=release-notes) - [YT video](https://youtu.be/4pNRUz0bNIU)
-
-## Credits
-
-This edition of Git Rev News was curated by
-Christian Couder <>,
-Jakub Narębski <>,
-Markus Jansen <> and
-Kaartic Sivaraam <>
-with help from XXX.
diff --git a/rev_news/drafts/edition-129.md b/rev_news/drafts/edition-129.md
new file mode 100644
index 000000000..9a139ef9b
--- /dev/null
+++ b/rev_news/drafts/edition-129.md
@@ -0,0 +1,94 @@
+---
+title: Git Rev News Edition 129 (November 30th, 2025)
+layout: default
+date: 2025-11-30 12:06:51 +0100
+author: chriscool
+categories: [news]
+navbar: false
+---
+
+## Git Rev News: Edition 129 (November 30th, 2025)
+
+Welcome to the 129th 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](http://git.github.io).
+
+This edition covers what happened during the months of October and November 2025.
+
+## Discussions
+
+
+
+
+
+
+
+
+
+## Other News
+
+__Various__
+
+
+__Light reading__
+- [Version Control in the Age of AI: The Complete Guide](https://www.git-tower.com/blog/version-control-in-the-age-of-ai)
+
+
+__Git tools and sites__
+
+
+## Releases
+
++ Git [2.52.0](https://lore.kernel.org/git/xmqqh5usmvsd.fsf@gitster.g/),
+[2.52.0-rc2](https://lore.kernel.org/git/xmqqzf8rqihh.fsf@gitster.g/),
+[2.52.0-rc1](https://lore.kernel.org/git/xmqqqzubhyj9.fsf@gitster.g/),
+[2.52.0-rc0](https://lore.kernel.org/git/xmqqwm47t4x3.fsf@gitster.g/)
++ Git for Windows [v2.52.0(1)](https://github.com/git-for-windows/git/releases/tag/v2.52.0.windows.1),
+[v2.52.0-rc2(1)](https://github.com/git-for-windows/git/releases/tag/v2.52.0-rc2.windows.1),
+[v2.52.0-rc1(1)](https://github.com/git-for-windows/git/releases/tag/v2.52.0-rc1.windows.1),
+[v2.52.0-rc0(1)](https://github.com/git-for-windows/git/releases/tag/v2.52.0-rc0.windows.1)
++ GitLab [18.6.1, 18.5.3, 18.4.5](https://about.gitlab.com/releases/2025/11/26/patch-release-gitlab-18-6-1-released/),
+[18.6](https://about.gitlab.com/releases/2025/11/20/gitlab-18-6-released/),
+[18.5.2, 18.4.4, 18.3.6](https://about.gitlab.com/releases/2025/11/12/patch-release-gitlab-18-5-2-released/)
++ Bitbucket Data Center [10.1](https://confluence.atlassian.com/bitbucketserver/release-notes-872139866.html)
++ Gerrit Code Review [3.10.9](https://www.gerritcodereview.com/3.10.html#3109),
+[3.11.6](https://www.gerritcodereview.com/3.11.html#3116),
+[3.11.7](https://www.gerritcodereview.com/3.11.html#3117),
+[3.12.3](https://www.gerritcodereview.com/3.12.html#3123),
+[3.13.0-rc5](https://www.gerritcodereview.com/3.13.html#3130),
+[3.13.0](https://www.gerritcodereview.com/3.13.html#3130),
+[3.13.1](https://www.gerritcodereview.com/3.13.html#3131)
++ GitHub Enterprise [3.18.1](https://docs.github.com/enterprise-server@3.18/admin/release-notes#3.18.1),
+[3.17.7](https://docs.github.com/enterprise-server@3.17/admin/release-notes#3.17.7),
+[3.16.10](https://docs.github.com/enterprise-server@3.16/admin/release-notes#3.16.10),
+[3.15.14](https://docs.github.com/enterprise-server@3.15/admin/release-notes#3.15.14),
+[3.14.19](https://docs.github.com/enterprise-server@3.14/admin/release-notes#3.14.19)
++ GitKraken [11.6.0](https://help.gitkraken.com/gitkraken-desktop/current/)
++ GitHub Desktop [3.5.4](https://desktop.github.com/release-notes/)
++ Git Cola [4.16.1](https://github.com/git-cola/git-cola/releases/tag/v4.16.1)
++ GitButler [0.18.1](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.18.1),
+[0.18.0](https://github.com/gitbutlerapp/gitbutler/releases/tag/release/0.18.0)
++ Kinetic Merge [1.11.2](https://github.com/sageserpent-open/kineticMerge/releases/tag/v1.11.2),
+[1.11.1](https://github.com/sageserpent-open/kineticMerge/releases/tag/v1.11.1),
+[1.11.0](https://github.com/sageserpent-open/kineticMerge/releases/tag/v1.11.0)
++ Tower for Mac [15](https://www.git-tower.com/blog/tower-mac-15) ([YouTube tour](https://youtu.be/xTrxb2dJP8M))
++ Tower for Windows [10](https://www.git-tower.com/blog/tower-windows-10)
+
+## Credits
+
+This edition of Git Rev News was curated by
+Christian Couder <>,
+Jakub Narębski <>,
+Markus Jansen <> and
+Kaartic Sivaraam <>
+with help from Bruno Brito.