~mroik@TTBP

Don't expect well written entries. I use this as a "personal diary", it simply happens to be public.



23 september 2026

This past week I've attended Git Merge 2026 as a Git contributor. The event started with JJ day on the 16th, a day all about Jujutsu, a git compatible VCS. JJ day was followed by the actual Git Merge which happened on the 17th and the 18th. On the 17th there were a curated set of speakers and the 18th was structured in an unconference style.

I arrived on the 16th in the afternoon as I wasn't going to attend JJ day. I stayed in Lisbon up to the 21st, since I wanted to explore a bit of the city after the conference.

The speakers:

Tomas' talk was a dive into the history of the review process in software development, the current state and what we can expect in the future. It was an interesting talk and gave some interesting perspectives on the software development process.

Three important concepts before continuing (bullet point taken from Johannes Schindelin's ChatGPT summary 'cause I can't be bothered to rewatch the live recording):

The History of Code Review

According to Tomas validation is mostly solved thanks to AI. The models now are so good (at least the frontier ones) that you can actually be pretty sure that their understanding of the code is correct. Something that Tomas would like to see is better integration of the LLM with the various forges. As of now LLMs interact mainly through CI jobs and usually with very restrictive policies (for good reason). He'd like to give agents more direct access to the repositories through standardized interfaces that give agents a lot more control over the whole repository on the forge. I could see it working but giving a model unrestricted access to your code is not something that can be easily done. First of all, LLMs can't take responsibility for their mistakes, so even just giving it write access is problematic.

Rust in Git

This is an overview of the state of Rust in the Git codebase. The reasons it was introduced to the codebase and what we can expect in the future.

Git Meta

It's Scott's project to attatch more metadata to the commits (or even just blobs) in Git without the need to build a new system on top of Git. His tool does everything using what's already available in Git (mostly), as in the rappresentation for data uses the serialization that can already be found in Git. The idea behind this is the fact that we already encode a lot of metadata that Git doesn't treat as special or can't categorize. An example are the trailers in commit messages, we encode Change-IDs, metadata regarding the authors or the LLMs we used to help us out. This metadata is not only useful for us developers that read back on the history, but also on LLMs, that require more and more information to produce better output (there are already some projects that try to encode metadata for future reference for LLMs).

Scaling Git for the AI Era

This shows some of the limitations that became apparent with the adoption of AI. The fact that we now produce a lot more code makes git even worse at scaling that it already is. Elijah presents some of solutions he implemented to overcome these challenges.

Josh: Beyond subtrees

It's about Josh, a tool for subtree projections. Useful for monorepos apparently but I wouldn't know, I never used subtrees and I have never worked on monorepos (besides, many use JJ for such usecases. At lunch on the 18th I had the pleasure to talk with a Google Engineering Manager and he told me that they started developing JJ specifically because Git scales so bad. I asked if they were planning to switch back to Git since we now have pluggable backends for objects (more on this later with Patrick Steinhardt) but he said they'll most likely stick to JJ.

Checking out another branch of Version Control

The speakers work on Mercurial and showcase some of its srengths compared to Git as an exchange of ideas.

Rebuilding Git

This talk is by Patrick Steinhardt, Staff Engineer at GitLab. His talk focused on his (and of many other contributors) efforts towards pluggable backends. This was needed due to Git's scaling issues, that became even more apparent with the AI boom. We can now write custom backend implementations for objects and references stores. This could allow forges to better leverage the use of S3 object stores (or any other efficient way they can come up with to better store repository data).

The Git Forge Must Be Hackable

This talk was done by the guys at Tangled. It's a new forge that aims to be hackable and leverage open formats to avoid vendor locking yourself with a specific provider. By that time I was a bit tired so I really couldn't pay too much attention to the architecture.

Git Smartlog

It's a talk about better representation of data in the CLI. Be it the history of commits being worked on.

SHA-256 at a Hyperscaler

Currently Git uses SHA-1 as its hashing algorithm for anything. SHA-256 is available and it will be the default starting with Git 3.0 (that is projected to be released in Spring 2027, there will be a LTS of git 2.XX with 2.99). Git does not allow mix-matching of these algorithms, so you either use SHA-1 or use SHA-256. This will force any project that whishes to not be exposed to supply-chain attacks to have to rehash the whole project, and if they have dependencies that are under submodules... well, good luck coordinating the migration, like I said, no mix-matching and that's on purpose for security reasons. There are some tools that will be available for interoperability but meh. In this talk Emily shows the possible migration stages that they'll be using at Google to finally use SHA-256 for all of their projects. The talk gives it a bleak spin, not sure if that's what Emily wanted to convey. Not very reassuring T_T

On the 18th I didn't attend the unconference style day but I instead attended the Contributor's summit, where every year contributors meet face to face (through video call if they can't make it) to align on the Git project. This is a great opportunity for companies to coordinate around specific features of Git. An example, Git 3.0 is projected to be released in Spring 2027 and not before the end of the year like it was projected last year, because GitHub still only has experimental support for SHA-256 and it's in private preview. They also wanted to release 2.98 before 2.99 as a signal that there will be a big change, and give time to other projects that are not as relevant as GitHub or GitLab time to adapt to the changes. Together with Git 3.0 2.99 will be released as an LTS, so we'll have 3.0.X in parallel with 2.99.X. This is because many architectures don't support LLVM which is a requirement for Rust and Rust will be mandatory to build Git 3.0.
This was only an example of how various projects that depend on Git coordinate. It was interesting seeing how everyone forwards its own agenda in a collaborative way. There are of course some issues various contributors don't agree on, an example of this was on the AI policy to implement, which has been a long issue as the Git project is not strong enough on assuming one position or the other. I'm not going to share what I heard but there were clearly some opposing views on the matter (Though Johannes Schindelin has released his own notes of the Contributor's summit [1]).

I'm glad I was able to attend Git Merge and the Contributor's summit. I was able to put faces to the names I so often see on the list, meet new interesting people and see how the "politics" around the Git project shape it.

If I feel like it I'll make another post on how I spent the remaining days I had in Lisbon, we'll see...

[1] https://lore.kernel.org/git/5cc325c6-579e-4fed-7071-a3ff98d51ccb@gmx.de/

permalink