Git Rev News: Edition 140 (October 31st, 2026)

Welcome to the 140th 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 September and October 2026.

Discussions

Reviews

Aleksei Sviridkin sent a small patch to the mailing list. It fixed a bug that made git push --force-if-includes reject valid forced pushes.

Some background about --force-if-includes

A plain git push --force overwrites the remote branch whatever it points to, so it can throw away commits that someone else pushed in the meantime. Option --force-with-lease is the safer alternative: the push is refused if the remote branch no longer points to the commit that the local remote-tracking ref (like origin/main) records.

That protection is defeated though when something, for example an IDE, runs git fetch in the background. The remote-tracking ref then gets updated without the user ever looking at the new commits, and the lease check passes. To solve this, Srinidhi Kaushik added --force-if-includes in Git 2.30 with commit 99a1f9ae10 (push: add reflog check for “–force-if-includes”, 2020-10-03), after a long patch series. The push.useForceIfIncludes config option enables it by default.

With this option, Git checks that the commit at the tip of the remote ref has been integrated locally at some point. To do this, is_reachable_in_reflog() walks the reflog of the local branch. It looks for that commit in the reflog entries, or failing that, for entries that can reach it. As an optimization, the walk stops at entries older than the newest entry in the reflog of the remote-tracking ref, because the local branch could not have been built on a remote commit before it was fetched.

The initial patch

Aleksei explained that the timestamp used for this cut-off is read by a callback passed to refs_for_each_reflog_ent_reverse(). When the remote-tracking ref has no reflog, the callback never runs, and the variable holding the timestamp is never initialized.

With the “files” ref backend, a remote-tracking ref created by git clone has no reflog until it moves. On Aleksei’s machine (macOS, arm64) the value left on the stack was bigger than any real timestamp. So the walk stopped at the very first entry, never reached the “Created from” entry written when the branch was created, and the push was rejected with “remote ref updated since checkout”, even though nothing had changed on the remote.

The fix was a one-line change initializing the variable to 0. The patch also added a test to “t5533-push-cas.sh”, which Aleksei warned could pass “by luck” on other platforms. The patch had an Assisted-by: LLM trailer before the Signed-off-by: trailer.

An Assisted-by: trailer side discussion

Junio Hamano, the Git maintainer, replied that the code change looked good. He said the sign-off must be the last trailer, because the author is “fully responsible for whatever LLM emitted”, and that “LLM” on its own gave no useful information. He also suggested moving test_when_finished up, so that cleanup also happens if the setup commands fail. Junio was surprised that a bug from a six-year-old change was only being noticed now. Aleksei answered that whether the bug triggers depends on the build and the stack layout, not really on the platform.

Aleksei said he had followed the Linux kernel rules for the trailer, as Git’s guidelines didn’t cover it. Junio pointed to the AI section in “Documentation/SubmittingPatches”. It says that the project “will reject anything that looks AI generated” or that senders “don’t understand or cannot explain”. Aleksei then cited Christian Brauner’s kernel commit 816d9992d9ed (coding-assistants: simplify attribution). It replaced model names in the kernel’s Assisted-by: trailers with a bare “LLM”, because naming models “provides free advertising to proprietary software companies”. He added that his patch had gone through a router mixing models from three vendors.

Kristoffer Haugsbakk wondered why, when Git’s guidelines say nothing, the “fallback guideline becomes the one for an operating system kernel”. Junio added “We are not the kernel ;-)”. He also said he would rather not have patches with “walls of text” whose origin can’t be known, and that he preferred “human-readable explanations and known origin”. As a consequence, Aleksei dropped the trailer.

Kristoffer later commented on the “uncanny valley” feeling he got from the LLM-like phrasing in replies to reviewers, and joked that he would have expected LLM-assisted commit messages “to read more like Jeff King log messages”. After a “;-)” from Junio, Thomas Bachem offered to ask for that in his next reroll, and Weijie Yuan said he already fed “a few representative patch series from Peff” to an LLM in his toy projects.

Is zero the right fallback?

Meanwhile, Aleksei sent version 2 of the patch, which moved the sign-off last and fixed the test cleanup.

Junio asked why 0 was a reasonable fallback value, rather than “now” or “2 weeks ago”, and what it means to pretend that the latest remote-tracking reflog entry dates from 1970. He also suggested a small rewording of the commit message.

Aleksei then sent version 3. Its commit message used Junio’s wording, and it argued that without a reflog there is nothing to base a cut-off on. It said “now” would bring the bug back, and a fixed age would cut the walk off too early in some cases. It also dropped the Assisted-by: trailer.

A few hours later, Junio suggested that gc.reflogExpire, or 90 days ago, would be “a lot more reasonable than year 1970”. Even an old, enabled reflog normally has no entries older than that, as they get expired.

Aleksei objected that reflog entries are only expired when git gc or git reflog expire runs. He built a scenario where a 90-day cut-off rejects a push that 0 lets through. Junio thought such repositories would only exist for those who “consciously disable the gc”, and that 0 would impose a slower full walk on everyone.

Aleksei disagreed again. A plain git clone with the “files” backend creates no remote-tracking reflog, and git gc --auto only runs once there are more than 6700 loose objects (the default gc.auto value), so a quiet repository expires nothing. He also posted timings with 20000 reflog entries. The full walk only took longer, about 0.3s instead of 0.07s, in a repository still holding entries older than 90 days. Junio found that this showed the gc expiration cut-off never wasted more time. Aleksei agreed, but pointed out: “The cutoff is faster than zero only where it gives the wrong answer.”

Two weeks later, Tyler Cipriani, who was working on his own --force-if-includes fixes, said he liked date=0. Both values give the right answer in most cases, but the cut-off can give a wrong one, and “the wrong answer is worse”. He described a simple scenario with default gc settings where the cut-off fails: clone, start rewriting history, do nothing for 90 days, then finish and force-push. He noted that 0 also avoids having to choose between gc.reflogExpire, per-ref settings or gc.reflogExpire=never. Junio agreed that when a reflog has never been expired, using all the available information always works better than using a cut-off.

Polishing the commit message and the test

Tyler then reviewed version 3. He said the code looked right, and that a wrong rejection with advice to pull would push him “(pun intended)” to drop the config option and the feature altogether.

He measured the cost on linux.git with 2000 reflog entries: 15ms with a commit-graph, but two minutes without one. That is because each batched call to repo_in_merge_bases_many() walks the history from scratch. He noted that doubling the batch size after each call brought this down to 10s, a possible optimization for a separate patch.

Tyler also found the last paragraph of the commit message hard to read, and even technically wrong: it suggested that a walk stopped by the cut-off skips the merge-base check. He found that without the fix, the test still passed on his Linux x86_64 machine, where the uninitialized value happened to be 2. It failed reliably only when built with make CFLAGS_APPEND=-ftrivial-auto-var-init=pattern, so CI would probably not catch a similar regression. He suggested using the setup_src_dup_dst helper in the test, like the surrounding tests. Junio noted that the patch had trivial textual conflicts in t5533 with Tyler’s topic.

Aleksei sent version 4 with a rewritten commit message that fixed the two inaccuracies Tyler had found. It explained that the record of the last move of the remote-tracking ref can be “never written, deleted, or expired by gc”. The test now used setup_src_dup_dst and expired only the remote-tracking reflog. Aleksei confirmed that it passed with both the “files” and “reftable” backends.

Junio found both changes sensible, thanked Aleksei and Tyler, and said he would mark the patch for ‘next’.

Conclusion

The fix itself was a single line, but the discussion went well beyond it. Reviewers asked why zero was the right value, and the patch was then backed by concrete scenarios and measurements, ending with the principle that a wrong answer is worse than a slow one. The thread also showed that bugs caused by uninitialized variables can hide for years, and that compiler options like -ftrivial-auto-var-init=pattern help to reveal them. It also provided an opportunity to clarify the project’s stance on Assisted-by: trailers and AI-assisted contributions.

The patch was merged into the ‘master’ branch on October 6, 2026. It will be part of the upcoming Git 2.98.0 release, and the release notes say it will later be merged to ‘maint’ too. Tyler’s related --force-if-includes fixes were still in ‘seen’ at the time of writing.

Developer Spotlight: Pablo Sabater

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 GSoC 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 Pablo Sabater, a Computer Science and Engineering undergraduate from Spain. I study at the University of Murcia but I’m currently living in Lisbon studying at NOVA FCT. I’m into low-level systems programming, mostly C, apart from Git.

    Apart from coding I really enjoy cooking.

    This summer I was a GSoC contributor at Git, mentored by Karthik Nayak and Chandra Pratap.

  • How did you initially become interested in contributing to Git, and what motivated you to choose it as your GSoC project?

    Paco told me about GSoC, and Git was one of the organizations that caught my attention the most, it’s a tool I use every day and I wanted to know how it really works. I started contributing around March 2026 with small patches (little time for the proposal deadline haha).

    The project was completing remote-object-info for the git cat-file --batch-command. It had already gone through Calvin Wan and Eric Ju, same as some series that I had merged at the beginning when I tried finding the best visual output as testing it would be “easier”, and I just like to see what I have worked on. That’s why I’ve also worked on the graph machinery. So, completing a command seemed very interesting and visual for me.

  • How do you feel your contribution has impacted the Git community or the broader open source ecosystem?

    Protocol v2 had the server side of object-info since 2021, but no client was using it. Now git cat-file --batch-command can ask a remote for the size and the type of an object without downloading it. That’s useful for partial clones, large repos, and tools that only need metadata.

    However, sadly it is not an option that many forges have activated.

    Outside of GSoC, I also added --graph-lane-limit and visual root indentation to git log --graph and some tiny fixes. I don’t think they have huge impact but at least some?

    Maybe the best contribution is that when I’ve seen someone on the #my-first-contribution channel on Discord, I tried to review their patches quickly and help them out.

  • Is there any aspect of Git that you now see differently after having contributed to it?

    There is a lot of backward compatibility. Some parts are not very pretty to look at and now I get more interested in the commands I use.

  • How do you balance your contributions with other responsibilities like work or school?

    Not as well as I’d have liked. Luckily I was in summer and I had no classes, but I tend to let things that I like absorb me. However I still enjoyed the summer with my friends, sometimes I worked in advance to not work in some days, and some other day I brought the laptop to camping.

  • Can you share how GSoC helped enhance your technical and non-technical skills (like communication, project management, etc.)?

    Technically, I learned how Git works internally, and Git has some very good parts that I have also learned from and helped improve my C coding.

    Non-technically, I improved how I review other people’s work.

  • What was your biggest takeaway or learning from GSoC that you now apply regularly in your work?

    I was a frequent user of git commit -m "", and after GSoC I enjoy making small commits with their full body and having linear histories on my own project (I even try to make my friends do the same).

  • What was the biggest challenge you faced during your contributions to Git, and how did you overcome it?

    Maybe fear of repercussions? I know it sounds ridiculous (more after meeting a lot of Git contributors). Everyone is so nice. In the beginning, though, the mailing list acts like an “evil filter”.

    Regarding coding, I think usually things are easier when you start from scratch. This time, I was in a huge codebase of code that I didn’t know and had to pull a series not written by me from scratch.

  • Have you thought about mentoring new GSoC / Outreachy students?

    Yes, I’d love to. I was planning to mentor Outreachy this year but I overestimated my time here in Lisbon and I had to drop out.

    I hope to mentor in the future.

  • 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 mean, everyone is already doing a lot of things, and I still don’t know a LOT of Git. I like to say that one doesn’t know what it lacks until they know what it has.

    But I see interesting work on VFS and LFS, and I’d love good documentation throughout the codebase.

  • If you could remove something from Git without worrying about backwards compatibility, what would it be?

    I don’t know, sorry.

  • What upcoming features or changes in Git are you particularly excited about?

    I think that the one I’m most excited of is the pluggable backends. Even though I don’t work at any big corp that would use it, I’m sure that I’m going to have fun trying it.

  • What is your favorite Git-related tool/library, outside of Git itself?

    b4, as it made the work of sending things to a mailing list so easy.

  • What is your toolbox for interacting with the mailing list and for development of Git?

    I code on neovim as I like to keep most of my stuff on the terminal; to review others, I download the thread as mbox and then use aerc to answer; to send my work I now use b4.

    One command that I didn’t know until recently that Git has on its codebase is git clang-format --diff, for which I sadly don’t remember who told me about it. Before knowing about it, I always had style complaints on my series.

  • How do you envision your own involvement with Git or other open source projects in the future?

    I want to keep contributing to Git, become better at it and treat it as if it was my own project. I also want to get involved in other open source projects, for example I’m trying with a friend to build a proper e-ink simulator on top of open source hardware.

    I see that Git, even though it is a huge project, the actual number of people that you see daily on the mailing list is in fact small. At Git Merge everyone knows each other. I want something like that.

    And of course I would love to have an idea that leads into a big open source project with community.

  • What is your advice for people who want to start Git development? Where and how should they start?

    I’d say that even if you are lazy, reading documentation will save so much time in the long run that it’s worth it. The people on the mailing list are very nice and to take their time, there is no joy in rushing things.

  • 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?

    Totally, it’s one of the best experiences that I’ve had.

    I want to mention Tian, Jayatheerth and Siddharth, the other 3 GSoC contributors to Git this summer, and of course Karthik and Chandra, my mentors.

Other News

Various

Newsletters

Easy watching

Light reading

Scientific preprints

Git tools and sites

  • LearnGit.io v2 is here. A rethink of LearnGit from the ground up that makes progression easier & more intuitive. LearnGit.io teaches Git with animated visualizations of Git internals, added quizzes, step-by-step interactive scenarios, and type-it-yourself exercises with a terminal emulator showing real commands and a visualization of the full Git tree, including branch pointers and commits. The first two modules are open to anyone without an account. LearnGit.io is free for students & educators.
    LearnGit.io was mentioned in Git Rev News Edition #108, #127, and #136 (in passing).
  • FluxGit Git School is a free set of nine guided Git exercises and a playground, available in eleven languages. It uses an in-memory simulated repository, without accessing local files or connecting to real Git remotes. Exercises cover misplaced commits, reset recovery, deleted branches, detached HEAD, conflicts and divergent branches. The simulator supports a subset of Git commands. No account or installation is needed to practise. Each exercise connects to the relevant written guide where one exists; existing video tutorials are linked alongside them.
  • Git-ing Over It is a browser-based game that hands you a real broken repo and makes you figure out what to run, the way you actually learn Git at work. Built by Ketuman Vishwakarma. Progress lives only in the browser; it never syncs or leaves your device.
  • Git Game: a multiplayer card game whose rules are Git. Ship commits to a shared main. Pull before you push, blame the bugs you can’t see, and survive git push --force. Free, in your browser, with nothing to sign up for. You can play against the bot, or in a room with your friends.
  • Gitualize is a web app to help you learn Git visually. Every Git command is animated step by step on the same small project — so you see what it really does to your files, your history and your remote.
  • The Animated Git Cheat Sheet is a website that uses git-sim to build an animated Git cheat sheet you can customize, with just the commands you need.
    Git Sim was first mentioned in Git Rev News Edition #95.
  • fremforge is an European alternative to GitHub and GitLab: Git hosting and CI/CD on one platform. One flat price, per seat, in EUR. Hosted in Germany, uses Forgejo.
  • Haxy is a self-hosted Git forge that is local-first and text-based. Haxy has a text user interface (TUI) that you can view in your terminal or on the web. It stores project metadata (issues, pull requests, and discussions) in the repo, and provide a TUI that is served over SSH, in addition to a web UI. Written in Zig, under MIT license (Expat).
    See also Haxy.net is live! — HAXY (git forge) devlog [7:31] video on YouTube.
  • Mochi Forge is a self-hosted Git forge, GitHub-shaped: repository browsing, in-browser editing, issues, pull requests, releases, Actions-style workflows, static sites, and Git LFS. One Node process, no database, nothing installed beside it but Git. Written in TypeScript, under Apache 2.0 license.
  • walgitgub is walgit with a GitHub Enterprise Server facade — a Git server that is one binary in front of an object store (e.g., S3 or GCS bucket). Written in Rust, under MIT license.
  • grubby is a static site generator for Git repos written in Ruby. Under GPL 3.0 license. This project is in an alpha state.
  • NeoLeaf is the online collaborative LaTeX editor that charges you absolutely nothing. Unlimited real-time collaboration, native version control (Git) on GitHub or Codeberg, and compilation on your own machine (with WASM / WebAssembly), with no waiting queues, no artificial timeout limits, and no monthly fees.
    • Compare with Aldine, a self-hosted, open-source LaTeX collaboration platform, an Overleaf alternative built for speed and simplicity (mentioned in Git Rev News #139).
  • Promptuaria is a place to write, publish and reuse software specifications as Markdown. Each published version is immutable and has a permanent address; Drafts stay private to their author until published.
    Promptuaria is an early public service. Expect rough edges.
  • memsaga: version control and two-way sync for your AI coding agent’s files, starting with Claude Code: what it remembers, how you configure it, and anything else you choose. Written in Rust, under MIT license.
  • ADRs4AI (Architectural Deliberation Records for Artificial Intelligence) is the template (repository starter), a VS Code extension, and Awesome ADRs4AI list. The idea is to keep the thinking, the most valuable byproduct of the collaboration between a human and an AI.
  • Mnemosyne is a version control for AI agent memory. Mnemosyne gives agent memory what Git gives code: commits, branches, merge, blame and bisect. Written in Rust and Python, under Apache 2.0 license.
  • Git for Global Law by Lexifina: the law of every country as one Git history, each country’s record a submodule, every commit one law taking effect. An expansion of the same for the US Code. Semantic, searchable law on a global scale.
  • Words To Data is a tool that lets you and your agents manage the The U.S. Code, the laws that change it, and the court opinions that cite it, as one dataset. words_to_data is a Rust command and library. It builds a SQLite dataset from public sources, and it answers questions about that dataset. SLEUTH-pi is the official agent. It runs in the pi coding agent. Under MIT or Apache-2.0 license, at your option (dual-licensed).
  • Crenox is a statically compiled, zero-dependency Git pre-commit secret scanner and credentials detector written in Go, under AGPL 3.0 license. It automatically blocks commits of API keys, SSH private keys, cloud credentials, database connection strings, and other sensitive material before they are recorded in version control history. An alternative to Gitleaks (first mentioned in Git Rev News Edition #36), truffleHog (first mentioned in Edition #23), betterleaks, and git-secrets (first mentioned in Edition #25), focusing on lower resource utilization and local workflow integration.
  • Gitby is a real-time coordination layer around Git. It shows who is working on which file (after claiming it), so your team can hand files over before two people edit the same one. A file someone else holds is read-only in every editor, so nobody changes it by accident. Gitby runs in your terminal (as TUI tool) and on the website. Supports GitHub. Paid service, with 3 teammates per team in a free tier.
    • Compare with the GitLive extension for Visual Studio Code, JetBrain IDEs, Cursor, Windsurf, Trae, Antigravity, etc. It provides preemptive merge conflict detection, with gutter indicators in the editor showing the lines that have been changed on other branches, while the repository view compares your branch against all others without needing to fetch.
      GitLive is free for open-source projects; there is also a free plan with merge conflict detection limited to the 5 most recent branches, and no real-time sharing (you can share snapshots of your working tree changes), as compared to the premium plan.
      GitLive was first mentioned in Git Rev News Edition #77 (as then a Visual Studio Code extension), and then in Edition #82.
  • AngKorGit is a native Git client for everyday work, with support for macOS, Windows and Linux. The engine is libgit2 through Rust, the window is the webview (not full web browser). Written in TypeScript and Rust, using the Tauri framework, under MIT license.
  • Diffy is a native Git diff viewer built in Rust with GPUI Kit. Review live changes, keep worktrees together, and read GitHub pull requests without checking out a branch. macOS is in beta; Windows and Linux are early alphas with limited hardware testing. Under MIT license.
    Mentioned in passing in Git Rev News Edition #132.
  • gitst: a real-time, glanceable Git status monitor for the terminal. Gitst shows in real-time what is happening to a Git repository (local as well as remote) as it happens: changed files, commits, pushes, fetches, merges, and rebases. It typically sits in one pane of a multi-pane terminal setup (using tools like Dantty, tmux, screen, herdr, WezTerm, iTerm2, etc.). Written in Rust, under MIT license.
  • uhegit provides Git status for your entire workspace — see what’s uncommitted, what’s unpushed, and what task to do next across all your projects. Written in Rust, under MIT license.
  • git-found is a Git credential helper for people with more than one GitHub account. It checks which of your accounts can reach a repo and gives Git that account’s token. Written as a Bash shell script, under MIT license.
  • git-cl (Git Changelists) is a command-line tool that brings changelist support to Git, inspired by Subversion. It adds a pre-staging review layer that lets you organise modified files into named groups before staging or committing. Changelists can be stashed selectively and promoted to dedicated branches — enabling a late-binding branching workflow, where the branch decision follows the code, not the other way around. Written in Python, under BSD-3-Clause license. Available as git-changelists on PyPI.
  • gsw — Git Smart Switch is an fzf-powered branch picker sorted by recent commits, with live log preview, remote toggle, and safe delete. A single Bash script, under MIT license.
  • git-dupe is a CLI tool to manage second Git repository for the files in a checkout that are yours and not the project’s: notes, plans, scratch scripts, editor settings, the instructions and skills you keep for a coding agent. The files stay where their tools expect them in the working tree. Their history lives in a repository of their own. Written in Rust, under MIT license.
  • grip is a per-push Git hook that won’t let you push code you can’t explain. It quizzes you on your own diff before allowing the push. Works with Claude Code, Codex, Cursor. Written in Python, under BSD-3-Clause license.
  • pretty-git-tree is a tool and a service (with examples) that turns a slice of Git history into different types of diagrams: arches, delta, Feynman diagram (particles), qubits, etc. Written in TypeScript, under MIT license.
  • Phloem is an on-line service where you can watch a repository grow like a slime mold. Paste a public GitHub repository (optionally providing a GitHub token), or upload a Git log instead (with specified invocation): folders become junctions, files become food, and every commit feeds the network. Written in TypeScript, under MIT license.
  • StateTrack provides Infrastructure Change Intelligence — Git history for live servers. A config edit, a package upgrade, a stopped IIS app pool, or a row flipped in settings_db is captured as a reviewable diff with an actor attached, seconds after it happens. Dashboard for GitDevOps. Written in Go, under Apache 2.0 license.
  • monolog is a keyboard-driven personal backlog that lives in a Git repo you own — no cloud, no account, plain-text data. Written in Go, under MIT license.
  • Hold My Docs (HMD) is a browser-based place to write, find and share documentation: a personal knowledge base, a team’s internal guides or a public docs site. Pages are Markdown files in a Git repository, so you can back them up or edit them with other tools. Written in Go, under MIT 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 Pablo Sabater, Okhuomon Ajayi, Björn Fock, Štěpán Němec, FluxGit, Jack Lot, and Spencer Uresk.