Git Rev News: Edition 119 (January 31st, 2025)

Welcome to the 119th 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 December 2024 and January 2025.

Discussions

Support

  • git support for “xattrs” (extended filesystem attributes)?

    Peter B. asked on the Git mailing list if there was a way to store extended attributes (xattrs) in Git. His use case was professional archival collection and he needed bit-proof preservation of all xattrs, even larger ones.

    Junio Hamano, the Git maintainer, replied that Git only tracks “contents, pathnames where these contents are stored, and the executable bit”.

    Jeff King, alias Peff, also replied to Peter confirming that Git, like most other version control systems, doesn’t store most metadata, but pointing to other tools, etckeeper and metastore, that can help with storing them in a separate file and restoring them on checkout.

    Junio agreed with Peff that Git is extensible that way.

    brian m. carlson replied to Peter mentioning other possibilities. One is to use the .gitattributes files to store a few xattrs with values that are “well stored as text”, and then git ls-attr and a post-checkout hook to restore them.

    Another possibility is to use mtree utilities to store or restore metadata from or into mtree files. brian especially pointed to go-mtree which supports xattrs. As mtree is an extensible key-value format, brian uses it to store the install location of his dotfiles.

    Peter replied to brian thanking everyone for the suggestions and saying he would especially take a look at mtree and metastore. He thanked brian again in the following message, saying that go-mtree looked very promising and that he was going to look at post-checkout hooks.

Developer Spotlight: Justin Tobler

  • Who are you and what do you do?

    My name is Justin Tobler and I am a relatively new contributor to the Git project with my first contributions being made this last year. I work at GitLab and these days spend my time integrating Git into GitLab’s data access layer as well as upstreaming Git fixes/features.

  • What would you name your most important contribution to Git?

    Most of my contributions thus far have been relatively minor bug fixes, but one bug I found particularly interesting was with the table compaction algorithm in the new reftable reference backend. There was a theoretical scenario where certain Git operations could be performed and new tables written, but table compaction would never occur. This was found when tests on certain platforms started failing because of file descriptor limits being exceeded.

  • What are you doing on the Git project these days, and why?

    One topic I’m currently working on is introducing a way to generate batches of specific blob diffs. This is not particularly useful for users, but for Git servers it’s a nice feature.

    I still have much to learn about the project so I also enjoy looking into the inflight topics that pop on the mailing list.

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

    I don’t have anything specific in mind, but it would probably be along the lines of changes to make the Git CLI more consistent across its various commands.

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

    For my Git-related workflow, outside of GitLab, I primarily use the Git CLI for everything.

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

    For interacting with the mailing list my workflow primarily consists of using neomutt and git send-email, but I have also recently been exploring b4.

    For development, I use neovim as my editor with an assortment of plugins.

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

    If you are unfamiliar with the mailing workflow, GitGitGadget can help handle formatting patches and sending them off to the mailing list. My first couple of patch series used this tool and I found it useful to get started without having to be super familiar with git format-patch and git send-email. Other than that, I also find it very helpful to observe how other contributors submit patches and interact on the mailing list.

  • If there’s one tip you would like to share with other Git developers, what would it be?

    I appreciate when the authors of a patch series provide as much background as possible to the change being made. Reading incoming patch series is a great way to learn about the project and it is very helpful when the required context overhead is minimized.

Other News

Various

  • Highlights from Git 2.48 by Taylor Blau on GitHub Blog, about faster SHA-1 computations for checksums, adding option --remerge-diff to the git range-diff command, memory-leak-free tests, introducing the Meson build system, and more.
  • What’s new in Git 2.48.0? by Christian Couder on GitLab Blog, about the Meson build system, Git becoming memory-leak-free, improved bundle URI checks, adding reference consistency checks, more performant ‘reftables’ implementation, support for reflogs in git-refs migrate (to migrate to ‘reftables’), the ‘ref-filter’ subsystem optimizations, and more.
  • Git security vulnerabilities announced by Taylor Blau on GitHub Blog: CVE-2024-50349 (ANSI escape sequences in hostname and prompt for interactive credentials) and CVE-2024-52006 (specially-crafted repository URL and credential helpers).
  • Adam Johnson’s book “Boost Your Git DX” has been updated with 28 new pages of content. This book was first mentioned in Git Rev News Edition #104.

Light reading

Git tools and sites

  • Project Harmony (Harmony Agreements) is a community-centered group focused on contributor agreements for free and open source software (FOSS).
  • todo-md is a pre-commit hook written in Bash that automatically maintains a TODO.md file in your repository. It collects TODO: comments from your code and organizes them into a Markdown file, making it easy to track tasks and improvements. Under MIT license.
  • Yek (يک) is a fast Rust based tool to serialize (selected) text-based files in a repository or directory into a single file meant for LLM consumption. Mentions similar projects. 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 Justin Tobler, D. Ben Knoble, Brandon Pugh, Štěpán Němec and Adam Johnson.