Git Rev News: Edition 126 (August 31st, 2025)

Welcome to the 126th edition of Git 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 on 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

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

    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 by converting its homegrown unit test framework to use 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 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 "<message>", 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” guide is definitely a go-to resource for understanding how the project is structured and how to navigate the codebase. The 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

Light reading

Git tools and sites

  • 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 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.
  • Setup DVC Action by Iterative is a JavaScript action that can be used as a step in GitHub Actions.
    DVC (Data Version Control) was first mentioned in Git Rev News Edition #42 and many times since (most recently in Edition #116).
  • 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), 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 by Natalie Klestrup Röijezon (natkr) on natkr’s ramblings.
  • patch-hub is a TUI tool that streamlines the interaction of Linux developers with patches archived on lore.kernel.org. Written in Rust, under GPL 2.0 license.
    It is a spin-off of kw, a tool for helping Linux kernel developers in everyday tasks (which is written in shell, and is under GPL 2.0 license).
  • 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.
  • 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 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 Nushell script, also under GPL 3.0 license.
    • Forgejo 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.
  • git-revise is a Git subcommand and Python library for efficiently updating, splitting, and rearranging commits. Under MIT License.
    The Introducing git-revise blog post was mentioned in Git Rev News Edition #54.
  • 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 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 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 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 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 blog post by Mike Street on his blog.
  • 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 is a code forge optimized for single instance deployments. It is still a work in progress. Written in Rust, under AGPL license.
  • 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

Credits

This edition of Git Rev News was curated by Christian Couder <christian.couder@gmail.com>, Jakub Narębski <jnareb@gmail.com>, Markus Jansen <mja@jansen-preisler.de> and Kaartic Sivaraam <kaartic.sivaraam@gmail.com> with help from Štěpán Němec, Gerard Murphy, Seyi Kuforiji and Bruno Brito.