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.
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.
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.
Various
--remerge-diff to the git range-diff command,
memory-leak-free tests, introducing the Meson build system, and more.git-refs migrate (to migrate to ‘reftables’),
the ‘ref-filter’ subsystem optimizations, and more.Light reading
GOVERNANCE.md file template or generator,
as another recommended addition to README.md, LICENSE, and Code of Conduct.
Mergiraf’s GOVERNANCE.md
is his example - the goal here is to make it clear for project users
what one can do if there is an issue/bug, or if one wants to add a new feature to a project.git commit --fixup:reword=<commit>)
in Brandon Pugh’s TILs: Today I learned… (2024).Git tools and sites
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.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.