Latest edition

Git Rev News: Edition 132 (February 28th, 2026)

Welcome to the 132nd 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 January and February 2026.

Discussions

Support

• Slow git pack-refs –all

  Martin Fick started the discussion by reporting a significant performance issue where git pack-refs --all was taking over five minutes to complete on a large repository (~3M refs) hosted on an NFS filesystem. This delay was particularly problematic for Gerrit servers because Git holds the packed-refs.lock for nearly the entire duration, blocking other reference updates. Martin noted that JGit was able to perform the same operation in under 20 seconds on the same repository, suggesting the bottleneck was specific to the Git implementation.

  The packed-refs file is used by Git to store a large number of references in a single sorted file to avoid the overhead of many small “loose” reference files. However, updating this file requires rewriting it entirely, and Git typically verifies that objects exist and “peels” tags (finding the underlying object a tag points to) during this process.

  brian m. carlson replied to Martin, suggesting that the slowdown might be occurring in should_pack_ref() because Git needs to verify that the object at the end of a reference actually exists. brian also pointed out that NFS was likely a major factor, as the network latency involved in opening many pack files and checking loose objects can be substantial. He suggested setting receive.unpackLimit to 1 to reduce the number of loose objects created in the first place.

  Jeff King (alias Peff) explained that the packed-refs file stores “tag-peeling” information, which requires Git to open each object for newly written refs via peel_object() to read its header and determine its type. Peff noted that this logic resides in write_with_updates() within packed-backend.c.

  Martin conducted further testing using strace and drop_caches to eliminate filesystem caching interference. He discovered that while the actual write() calls were fast, there were long gaps—up to four minutes in total—where the program was not making any system calls. Martin hypothesized that this “hidden” time was spent by the kernel handling page faults for mmap()ed memory over NFS.

  Patrick Steinhardt concurred that NFS was frequently a source of such performance issues, mentioning that GitLab had eventually sunsetted the use of NFS for this reason. Patrick suggested using perf(1) to generate a flame graph to see exactly where the CPU was spending time.

  Martin provided a summary of a flame graph, which showed about one-third of the time spent in _memcmp_sse4_1 and another third in unpack_object_header_buffer(), both accompanied by high page fault rates. He also noticed significant time spent in a function he identified as packed_refs_store_create().

  Peff corrected the function name to packed_ref_store_create() and noted that Git might be performing an extra linear pass through the packed-refs file if it lacks certain header tags. He discovered that JGit-generated files were missing the sorted and fully-peeled traits in the header. Without the sorted tag, Git reads the entire file linearly to verify its order before it can perform binary searches. Peff suggested that JGit should be updated to write these markers.

  In a final breakthrough, Martin tested adding these tags manually. He found that while the sorted tag did not provide a major boost, adding the fully-peeled tag was the “trigger” that dropped the execution time from over five minutes to under four seconds. The absence of the fully-peeled tag was forcing Git to re-peel every reference by looking up the objects in the pack files over the slow NFS connection.

  Following that discovery, a fix was proposed for JGit in Change 1230152. Adithya Chakilam submitted the patch, titled “pack-refs: Add sorted/fully-peeled flags,” to ensure JGit produces packed-refs files that Git can process efficiently.

  This resolution not only fixes the immediate performance issue for Gerrit servers but also ensures that any environment using a mix of JGit and Git will benefit from reduced lock contention and faster reference updates.

Other News

Various

• What’s new in Git 2.53.0? by Justin Tobler on GitLab Blog. The described changes include fixes for geometric repacking (adding support for promisor remotes), updates to git fast-import commit signature handling options, and more data being available in git repo structure output.
• Git 2.53 Released with New Features and Performance Improvements by Marcus Nestor on 9to5Linux.
• Git 2.53 Released With More Optimizations, One Step Closer To Making Rust Mandatory by Michael Larabel on Phoronix.
• Gentoo Linux has kicked off its long transition away from Microsoft’s GitHub to Codeberg, an open-source Git-hosting service: see the PC Gamer article by Joshua Wolens, and the Gentoo on Codeberg article in Gentoo Linux News.
• Vinyl Cache project (formerly Varnish Cache) has left GitHub for the self hosted Forgejo instance: https://code.vinyl-cache.org/vinyl-cache/
• Game of Trees Hub’s web interface is live.
  • The Game of Trees Hub is a transparently funded Git repository hosting service, with infrastructure on OpenBSD and the Game of Trees (GoT) VCS, mentioned in the previous edition.
• Exploring Solutions to Tackle Low-Quality Contributions on GitHub by Camilla Moraes (@moraesc) on GitHub Community Discussions.
• The Former CEO of GitHub [Thomas Dohmke] Just Agreed: Git Wasn’t Built for This [AI-based coding] by Jeff Cameron on OpZero blog, following his “interview” with Claude Opus 4.5. The idea is to version code, intent, constraints, and reasoning together, and to add a semantic reasoning layer through a “context graph”. Thomas Dohmke has launched such an open-source developer platform for collaboration between developers and AI agents, Entire.
  • On one hand this assumes that AI generated code is a viable path to creating software, and there would be no technical problems like model collapse, or economical problems like cost of training and using LLMs.
  • On the other hand there exist specialized solutions to help version data (like DVC or Pachyderm) or database schemas.

Light reading

• Evolving Git for the next decade by Joe Brockmeier on LWN.net, reporting about Patrick Steinhardt’s (@pks-t) main track talk at FOSDEM 2026. The recording of this talk is available on the FOSDEM site.
• Exploring the .git Directory – How Git Stores Your Code by Bruno Brito on Tower’s Blog.
• The Ultimate Guide to Git Config: Fine-Tuning Your Git Experience by Bruno Brito on Tower’s Blog.
• TIL that pathnames in git configs can be optional by Anh Tuan Le on his blog. It mentions the fact that as of Git 2.52 (Nov 2025), you can mark config file paths as optional using the :(optional) prefix; see the ‘pathname’ entry in the “Values” section of the git config manpage.
• Git Reflog Explained: Recover Deleted Commits & Lost Work by Shakil Alam on DEV.to. Has a video version.
• How to Save Multiple Drafts in Git: A Guide to Using Git Stash by Chidiadi Anyanwu on freeCodeCamp.
• Git renames are not renames (and where it can cause problems) by Lorna Jane Mitchell on LornaJane Blog.
• The Many Flavors of Ignore Files by Andrew Nesbitt on his blog. The post talks about Git’s actual semantics for “gitignore syntax”.
  • The author wrote git-pkgs/gitignore, a Go library that fully matches how Git’s gitignore patterns work.
• git recent: what branch did I work on?, about a simple Git alias, by Remy Sharp on his blog.
• I Hate GitHub Actions with Passion by Przemysław Alexander Kamiński on his xlii.space blog.
  • The main problem is with trying to debug GitHub Actions problems when the action fails; Act, a command line tool to run your GitHub Actions locally using the Docker Engine API, could help there. Act was first mentioned in Git Rev News Edition #113.
  • There is also WRKFLW, a command-line tool for validating and executing GitHub Actions workflows locally, without requiring a full GitHub environment. WRKFLW was mentioned in Git Rev News Edition #126.
• GitHub Actions: The Hidden Billing Trap, on how to avoid unexpected costs with a simple settings adjustment. Written by Steven Hicks on TheExceptionCatcher.
• Git Worktrees with Claude Code, Laravel, and Herd by Jakub Gause on his blog (also published on DEV.to). Describes writing a shell script to help (a laravel-worktrees Claude skill).
• I Built workz: The Zoxide for Git Worktrees That Finally Fixes .env + node_modules Hell in 2026 by Rohan Sharma on DEV.to. Describes his workz tool that creates a new worktree, automatically symlinks 22+ types of dependency dirs (like node_modules, target, .venv), copies env/config patterns, and can launch your AI coding agent directly in the new worktree.
• Agent Identity for Git Commits by Justin Poehnelt on his blog, about how to set up AI agents to have their commits come from a bot account without modifying your local Git config.
• Your Secrets Aren’t Safe: How the .git Directory Can Leak Data via AI Tools by Yohei Seki on DEV.to. The problem is that a malicious MCP server or Skill can access leaked secrets even if they were removed from the project (you should treat any committed secret as compromised, and invalidate it; using git filter-repo or BFG RepoCleaner to rewrite history might be a choice). They can also access authentication information if embedded in .git/config.
• Git in Postgres by Andrew Nesbitt on his blog (following Package managers keep using git as a database, it never works out, mentioned in Git Rev News Edition #130 from December). In this post he describes how he created a Git backend using a relational database: gitgres (implementing the libgit2 git_odb_backend and git_refdb_backend interfaces against PostgreSQL through libpq). He acknowledges that right now gitgres is just a neat hack, as it currently does not implement delta compression; nevertheless it might be a good solution for small instances of software forges for small projects.
  • Compare with git-remote-sqlite, a Git remote protocol helper that helps you store a Git repository in a SQLite database, mentioned in Git Rev News Edition #127.
• The nightmare that is squash merge ft GitHub by Narendra Vardi on his blog, about how to fix merge conflicts caused by squash merge using interactive rebase.
• How Poor Git Branching Practices Quietly Damage Software Quality by AK DevCraft on Substack (and also on DEV.to), about the Environment-Based Branching antipattern.
  • The Patterns for Managing Source Code Branches by Martin Fowler, mentioned first in Git Rev News Edition #63, also talks about this antipattern.
• Why [pure] GitOps Doesn’t Work at Scale (and What to Do Instead) by Justin Brooks (@jsbrooks) at ctrlplane (also on DEV.to). He writes why enterprise scale workflows need platform-level orchestration.
• GitHub Actions Is Slowly Killing Your Engineering Team and No, Really, Bash Is Not Enough: Why Large-Scale CI Needs an Orchestrator by Ian Duncan on his blog.
• My self-hosted Git workflow with GitGen by cybrkyd; it continues Showcasing my Git repositories on the web from the previous edition.
  • GitGen is a lightweight static website generator for local Git repositories written in Python; similar tools are Gitmal and pgit, both written in Go.
• The bare minimum for syncing Git repos by Alex Chan on her blog.
• The Disconnected Git Workflow by Lionel Dricot (Ploum) (sidenote: there is also git-credential-oauth that can solve some of the problems with sending a small one-off patch to a GitHub project).
• git.usebox.net and bots by Juan J. Martínez on his Personal Log, about his modification of gitweb to block AI crawlers (that do not respect robots.txt).
• I Built a Tool That Writes Obituaries for Your Deleted Code and commit-prophet: I Built a Tool That Predicts Buggy Files Using Git History by Lakshmi Sravya Vedantham on DEV.to.
• I Read 9,000 Lines of a Stranger’s Mergetool by Wes on DEV.to, about the ec (easy-conflict) tool. This is the first entry in the Review Bomb series, where Wes finds under-the-radar projects on GitHub, reads the code, contributes something, and writes it up.
• Return to GitHub by Glyn Normington on the underlap blog; the move of ipc-channel-mux from Codeberg to GitHub was caused by the need for CI on macOS and Windows (without having to self-host CI runners).
• Simplifying Git by Using GitButler: seeing Git state, branching without fear, understanding and using stacked changes, better interactive rebase, easier selective staging, recoverability. Written by PJ Hagerty on GitButler Blog. Git Butler was first mentioned in Git Rev News Edition #46.
• GitButler CLI Is Really Good by @matdevdug on matduggan.com.

• Introducing jjq, a local merge queue for jj by Paul Smith on his blog. Jujutsu (jj) is a Git-compatible version control system written in Rust, which was first mentioned in Git Rev News Edition #85.

• 15+ years later, Microsoft morged my diagram by Vincent Driessen, on how Microsoft’s Learn portal included an AI generated diagram with the rough shape of the one in the A successful Git branching model, but with some GenAI glitches (like the text “Bugfixes from rel, branch may be continvoucly morged back into develop”), and arrows missing or pointing in the wrong direction, or missing the node. The image has been replaced since then; you can see the original compared to the Microsoft one in the PC Gamer article about this issue.

Easy watching

• Evolving Git for the next decade by Patrick Steinhardt [47:46], a main track talk at FOSDEM (Free and Open source Software Developers’ European Meeting), given on Saturday, 31 January 2026, Brussels. See also the summary of this talk by Joe Brockmeier on LWN.net (mentioned in the “Light reading” section).
• An Efficient Git Workflow For High-Stakes Projects by Vladislav Shpilevoy [45:12], a main track talk at FOSDEM, on Saturday, 21 January 2026, Brussels. The example project this workflow was used in is tarantool.
• Pull requests maintainers will love to review by Alya Abbott, a main track talk at FOSDEM, on Saturday, 21 January 2026, Brussels. Slides available as Google Slides.
• Mercurial, 20 years and counting: how are we still alive and kicking? by Raphaël Gomès and Pierre-Yves David [50:02], a main track talk at FOSDEM, on Saturday, 21 January 2026, Brussels.
• Lost Your Commits? Git Reflog Saves You by Shakil Alam on the Shakil Tech channel on YouTube [5:55].
• Configure your Git by Denis Gruzdev aka @codingjerk on the codingjerk channel on YouTube [14:02]: a brief review on their personal git config / setup, showing some of the most used commands, settings, and aliases.

Git tools and sites

• mise-en-place or mise, a CLI tool that is the front-end to your dev env (managing dev tools like node, python, cmake, terraform, etc; and managing tasks used to build and test projects), introduced monorepo tasks, allowing you to manage tasks across multiple projects in a single repository, with each project maintaining its own tools, environment variables, and tasks.
  • A monorepo is a software-development strategy in which the code for a number of projects is stored in the same repository. See for example the monorepo.tools site, first mentioned in Git Rev News Edition #84.
• difi is a TUI tool that helps you review and refine Git diffs before you push. Written in Go using the Bubble Tea library, under MIT license.
• deff is a TUI tool providing interactive, side-by-side file review for Git diffs with per-file navigation, vertical and horizontal scrolling, syntax highlighting, and added/deleted line tinting. Written in Rust, under MIT license.
• ec (easy-conflict) is a terminal Git mergetool with a 3-way TUI and Neovim integration. Written in Go, under MIT license.
• Maiao: Gerrit-style code review workflow for GitHub. Maiao brings the power of stacked pull requests to GitHub, enabling you to break large features into small, reviewable commits where each commit becomes its own PR. Provides a git review command. Written in Go, under MIT license.
  • Stacked Pull Requests, also under the name Stacked Diffs, were mentioned in Git Rev News Edition #44, #105, #111 (with links to other editions with other articles, and to related tools), #115. #118, #127, and #128.
  • Compare with av, a command-line tool that helps you manage your stacked PRs on GitHub. It was mentioned in Git Rev News Edition #115.
  • GitButler, a Source Code Management system designed to manage your branches, also supports stacked branches, which was mentioned in Git Rev News Edition #118.
• Diffs, aka @pierre/diffs, is an open source diff and file rendering library built on the Shiki syntax highlighter. It supports split (side-by-side) or stacked (unified diff) layout, different diff highlight styles, in-line highlighting, wrapping, and line numbers. Includes an annotation framework for injecting comments and annotations, and more. Written in TypeScript, under Apache 2.0 license. Intended for use in web applications. Diffs is in early active development—APIs are subject to change.
  • Compare with diff2html (repo on GitHub), a pretty diff to HTML JavaScript library: diff parser and pretty HTML generator. Written in TypeScript, under MIT license. Provides diff2html-cli, used by, among others, Ungit, Diffy, git-explorer, Simple Git, git-tabular-diff. diff2html was first mentioned in Git Rev News Edition #98, and diff2html-cli in Git Rev News Edition #14.
• Gitnuro is a multiplatform Git client, based on JetBrains Compose and JGit. Written in Kotlin, under GPL 3.0 license.
• RelaGit - the elegant solution to graphical version control, is a multiplatform Git GUI written in TypeScript. Under LGPL 3.0 license. RelaGit is in early beta stage.
• SourceGit is an open-source Git GUI client that supports Windows, macOS, and Linux. Includes built-in conventional commit message helper, and support for using AI to generate commit messages. Written in C#, using the Avalonia cross-platform UI framework, under MIT license.
• git-toolbelt is a suite of useful Git commands that aid with scripting or every day command line usage. Written in shell, under BSD-3-Clause license.
  • See Git power tools for daily use by Vincent Driessen, the author of git-flow (2018).
• sqldef is a CLI tool for diffing two SQL schemas. You can use it to manage the migration of RDBMSs using regular SQL DDLs. Supported databases: MySQL, MariaDB, TiDB, PostgreSQL, SQL Server, and SQLite3. Written in Go, under MIT license (for everything except parser, which is under Apache 2.0 license). Compare with:
  • sqldiff.exe, a command-line utility program (Windows binary) that displays content differences between two SQLite databases, mentioned in Git Rev News Edition #87.
  • pg-diff, a PostgreSQL schema and data comparing tool written in JavaScript, mentioned in Git Rev News Edition #108.
  • git-sqlite, a custom diff and merge driver for SQLite, mentioned in Git Rev News Edition #127.
• Fresh File Explorer is a VS Code file explorer which shows only recently modified files based on a combination of Git history and your pending changes. Written in TypeScript, under MIT license.
  • See also Fresh File Explorer - vscode extension for navigating recent changes by Frederik Hudák on DEV.to.
• Git Remote Color is a VS Code extension that automatically colors your VS Code workspace based on the git remote URL: every repository gets its own unique, consistent color. Inspired by the Peacock extension, but fully automatic using a deterministic hash of the git remote.
  • See also VS Code Git Remote Color by Justin Poehnelt on his blog.
• commit-prophet is a command line tool that predicts which files are more likely to have bugs using Git history patterns and co-change analysis. Written in Python, under MIT license.
• Majutsu provides a Magit-style interface for Jujutsu (jj), offering an efficient way to interact with JJ repositories from within Emacs. Primary project license is GNU GPL v3 or later, but it was previously distributed under MIT license terms.
• The Missing GitHub Status Page is a third-party service that tracks 90 days uptime; created because GitHub stopped updating its GitHub Status page with aggregate uptime numbers.

Releases

• Git 2.53.0
• Git for Windows v2.53.0(1)
• GitLab 18.9.1, 18.8.5, 18.7.5, 18.9, 18.8.4, 18.7.4, 18.6.6, 18.6.2, 18.7.1, 18.8.1, 18.8.3, 18.7.3, 18.6.5
• Gerrit Code Review 3.11.9, 3.12.5, 3.13.3, 3.13.4
• GitHub Enterprise 3.20.0, 3.19.2, 3.18.5, 3.17.11, 3.16.14, 3.15.18, 3.14.23
• GitKraken 11.9.0
• GitHub Desktop 3.5.5
• Sourcetree 4.2.17
• Git Cola 4.17.1
• GitButler 0.19.3, 0.19.2
• Sublime Merge Build 2123
• Tower for Mac 15.1
• Tower for Windows 11
• git-flow-next 1.0

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 Bruno Brito, Michael Ryzhikov and Shreyansh Paliwal.