Git Rev News: Edition 128 (October 31st, 2025)

Welcome to the 128th 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 2025.

Discussions

General

Support

  • [Change] Git build issue on NonStop

    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 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 <inttypes.h>) 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). 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.

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

  • 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). People can use git-filter-repo(1). And with that one removed I wouldn’t have to ask people to not use it any more. ;)

  • 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) 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; the last time I saw something parameterized was when an AsciiDoc 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.

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

    Magit. An Emacs Git frontend.

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

  • 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) and git-send-email(1)). For programming and writing I use the basic, needed tools along with Emacs. Very occasionally I will use GDB.

  • 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. I don’t really see many corrections that refer to other documents. You could of course get a correction that refers to some lore but that is unlikely to happen for simple changes if you just structure it similar to recent, accepted submissions that you find.

  • 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)) 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) for years and years.

Other News

Various

Light reading

Easy watching

Scientific papers

  • Ya-Nan Li, Yaqing Song, Qiang Tang, Moti Yung: “End-to-End Encrypted Git Services”, Cryptology {ePrint} Archive, Paper 2025/1208, https://eprint.iacr.org/2025/1208, DOI:10.1145/3719027.3744815
  • S.R.P. van Hal, M. Post, K. Wendel: “Generating Commit Messages from Git Diffs”, arXiv: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 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 (wtm) is a fast, modern CLI tool for managing Git worktrees in bare repositories. Written in TypeScript for Bun, under MIT License.
  • 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 article by Jérémie Drouet on DEV.to (2024).
    • There is another 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.
  • 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, and most recently in Git Rev News #127, where you can find even more links about this technique.
  • Git Granary is a Git Large File Storage (LFS) server implementation written in TypeScript. Under MIT License. Git Granary was designed for self-hosted personal use.
    See Git Granary blog post by David Bushell on his blog (2024).
  • 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 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 engine it uses is open source (MIT License). It uses a LLM (Large Language Model) to perform this task.

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 Kristoffer Haugsbakk, Lee Reilly, Luca Milanesio and Štěpán Němec.