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.
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.
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.
Various
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), 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.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.Light reading
git-review
work-in-progress tool, and also the
jj) is a Git-compatible version control system
written in Rust, and was first mentioned in
Git Rev News Edition #85.git subtree to consolidate
hundreds of legacy experimental repos into an archive,
preserving all of the commit history.git filter-branch tool;
the recommended replacement is git filter-repo.
Also, you can correct the visible e-mail with the .mailmap file
(changing what Git shows, without having to rewrite history).git alias which examines
the terminal width, and then git status --column=nodense if the terminal is wide enough.git revise for splitting pull requests (PRs),
and custom git backup, git reparent, git split, git move-branch, and git bookmark commands.git rebase.git blame,
‘pickaxe’ search with git log -S, and a
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
.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.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-remote-files) that remembers where they came from
and what commit they belong to.
Written in Python, under GPL 2.0 license.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.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.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.