Re: My summary of the Git Contributors' Summit 2026, was Re: Git v3.0 timeline, was Re: What's cooking in git.git (Sep 2026, #08)

[Daniele Sassoli <danielesassoli@gmail.com>]

Hi Johannes,

Thanks so much for this summary, I didn't participate at the contributor 
summit
as I was leading one of the breakout sessions in the morning and had a 
plane to
catch in the afternoon, so I'm very grateful of your summary.

On 22/09/2026 19:44, Johannes Schindelin wrote:
> Hi Junio,
>
> On Tue, 22 Sep 2026, Junio C Hamano wrote:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>
>>> On Mon, 21 Sep 2026, Junio C Hamano wrote:
>>>
>>>> Git 2.56-rc1 has been tagged.  We may merge last-minute fixes before
>>>> the final Git 2.56 release, but otherwise I do not expect any new
>>>> feature topics to be ready before the final, so most of the
>>>> in-flight topics will stay cooking in 'next' until then.  As
>>>> discussed at the Git Contributors' Summit, the version after the
>>>> upcoming Git 2.56 will be Git 2.98, scheduled near the end of this
>>>> year.
>>> Would you say that the following is an accurate characterization of the
>>> timeline, so that people who need to plan dependent projects can rely on
>>> it?
>> My outline was deliberately limited up to end of this year as I am
>> hesitant to say beyond that point before the meeting notes are made
>> public.
> I originally wrote this summary of the Git Contributor Summit only for my
> own records, but since you hinted at wanting some meeting notes, figured
> it might be interesting to other people, too. So here goes my distillation
> of the breakout-sessions from this year's Contributors' Summit. Many of
> these ideas still need discussion on the list; proposals below are not
> project-wide decisions.
>
> Security mailing list and process
>
> The security list is seeing a large influx of outside reports, apparently
> often AI-assisted or generated. Duplicates and reports outside Git's
> security model consume triage time, while some patches have waited for
> months. Waiting for an empty queue is not a workable release criterion: we
> need to release the fixes we have, rather than hold them indefinitely
> while more reports arrive. No fixed release cadence or guaranteed response
> time was settled.
>
> Documenting Git's security model would save repeated explanations of what
> does and does not constitute a vulnerability. (Personal note, not
> discussed at the Summit: Stolee had tried to start a conversation about
> Git's security boundary a long time ago, but nobody replied. Maybe the AI
> onslaught will provide enough motivation to get that discussion going.)
> Moving non-security bugs to the public list more readily was also
> encouraged. A timeout after which public discussion would be presumed OK
> was proposed, but not agreed.
>
> More company staffing would help, without turning this into an obligation
> for volunteers. Paying for dedicated help was discussed, with onboarding
> costs a concern. Using AI for triage or fixes raises confidentiality and
> DCO questions of its own. (Personal note: There seemed to be some
> sentiment in the room that contradicted the earlier agreed-on finding on
> the mailing list that using AI for triaging and for investigating wasn't a
> copyright concern and should therefore be considered permissible.)
>
> The release bottleneck is not really tag automation. Merging and
> backporting fixes, preparing advisories, and handling CVEs take work, and
> too much of that knowledge lives in people's heads. Peff volunteered to
> start a public discussion of the process and dig up existing resources.
> (Personal note: I have done that merging, backporting, etc plenty of
> times, and I don't think that it is the bottleneck, and I was rather
> surprised to hear that it is complicated. Sure, there are the expected
> merge conflicts when merging `maint-*` branches, and running -- and
> fixing! -- CI on all of the tags in a private repository should go without
> saying, but that's all craft of the trade. Rather, the indecision and lack
> of engagement on the git-security mailing list is what I see as the
> blocker. I'd happily volunteer to juggle those branch thickets if that was
> truly the make-or-break issue here.)
>
> Microsoft's release process reportedly needs about seven weeks. There were
> no objections in the room to proceeding without waiting for that schedule.
> (Personal note: That release process was misrepresented, which is
> surprising, as I coordinated two or three Git for Windows security bugfix
> releases _on the git-security list_ since the most recent Git security
> bugfix release, it's always the same thing: release on a second Tuesday of
> the month, three weeks before that the patches need to have settled,
> everybody goes home with a dependable timeline. It's not really that big
> of a deal. Testing patches, constructive feedback, these are the things
> that are missing and therefore blocking the process. I sensed a lot of
> finger-pointing in this discussion. I mean, I don't blame anybody for
> avoiding security work: it is stressful and intense. The responsibility
> for getting things wrong is enormous. I know that because I've done my
> share of that, probably more than most in the Git project, and I will do
> even more in the future. But when I don't have the time, or the energy, I
> am aware that I, myself, am the bottleneck; I don't need to blame others.)
>
> Git v3.0
>
> The proposed target is spring 2027: v2.56 in September 2026, v2.98 in
> December, then v2.99 and v3.0 next spring. The jump in version numbers is
> intended to signal the approaching breaking changes. March and April were
> both mentioned; the precise timing is not settled.
>
> There was agreement on releasing v2.99.1 and v3.0 together, differing only
> in the BREAKING_CHANGES (v3.0 switches them on). That keeps the transition
> separate from another round of feature development. Nobody in the room
> objected to Rust becoming mandatory in v3.0. (Personal note: probably
> because Randall wasn't there, to say that NonStop support would be a
> blocker and that Git please wait.) A v2.x LTS remains an open question,
> with Gentoo mentioned as an interested party. (Personal note: I am still
> advocating for an in-tree Long Term Support branch, and since Junio
> indicated that he's less than eager to take care of that, I would love for
> Patrick Steinhardt to be the "LTS lieutenant", I vaguely remember that he
> said he'd do it if asked, and I trust his judgement, so I'd ask.)
>
> SHA-256 support across the ecosystem had been a blocker. GitHub reported
> experimental support, with general availability expected around November.
> GitLab already had public, non-experimental support, and libgit2 supports
> it, too. JGit remains a gap; Google was not planning to fund that work.
>
> The SHA-1/SHA-256 interoperability work, including historical tags, was
> reported to be implemented but not yet sent to the list. (Personal note: I
> think that the room seriously "mis-underestimated" the real-world impact
> of this. The code is not even on the Git mailing list, and the
> ramifications of not having a robust plan how to deal with partial clones
> or submodules or even signed tags strikes me as a dealbreaker. I would not
> be surprised if the decision to enforce SHA-256 as default would have to
> be revisited before v3.0, and possibly overturned.)
>
> Documentation
>
> Julia's work highlights the gap between documentation written by people
> who know Git inside out and users who do not yet know what objects, the
> index, or upstream mean. We need approachable learning material as well as
> reference documentation. Both need work; keeping manpages concise does not
> mean they cannot have better explanations and examples. (Personal note: I
> am beyond excited that Julia, whose work I have always admired, got
> interested in improving Git's documentation, which is in dear need of
> being improved, mainly because it does not cater to the majority of Git
> users out there who are unlikely to wander onto the Git mailing list,
> ever. I just hope that old-timers who really do not need the documentation
> nor understand the need of those who do need it show enough appreciation
> for the fresh views and for Julia's understanding of the target audience.)
>
> Discoverability matters, too. The website (https://git-scm.com/) needs
> clearer entry points for learning Git, and existing guides are harder to
> find than manpages. Missing subsection links are another improvement we
> could make incrementally. (Personal note: Judging by the history of that
> site, I do wonder whether the core Git contributors are interested in
> helping this effort at all. For example, there are a growing number of PRs
> suggesting to add new UIs to the growing list, but I gave up reviewing
> them because I was the only one doing so.)
>
> There was support for replacing outdated material and for merging useful
> improvements, then iterating, rather than trying to perfect everything
> before it lands. Bringing user feedback to the list without flooding it
> remains a challenge.
>
> The current funding covers only 100 hours split between two people.
> Additional project and company funding was encouraged; brian, Emily, and
> Mark offered to explore company support. (Personal note: I had tried, back
> when GitHub still funded my team, to start something like that, without
> any success. To the contrary, even Git for Windows and Git Credential
> Manager got defunded.)
>
> On the tooling side, using only Asciidoctor instead of maintaining both
> AsciiDoc and Asciidoctor support was proposed as a possible Git v3.0
> change. Distribution support and rendering differences need checking, with
> doc-diff suggested for comparing the outputs. Patrick filed an issue
> during the discussion. (Personal note: AFAIU the AsciiDoc spec is now
> maintained by Asciidoctor, and I am aware already of one change that was
> made to the spec without adapting AsciiDoc accordingly. So the entire
> discussion might be quite moot already.)
>
> Other ideas included richer diagrams for HTML while retaining text
> versions for manpages, and privacy-respecting traffic measurements to help
> prioritize documentation work. No diagram format was chosen, and caching
> and AI scraping complicate getting useful traffic data. Mermaid was
> proposed, and even GraphViz. (Personal note: I added support for Mermaid
> diagrams to https://git-scm.com/, but it turned out to be too limited, so
> I added GraphViz support. The support code for this is a bit of a beast,
> having a wasm version of GraphViz for development, pre-rendering the
> diagrams as SVG and as PDF during deployment of the site; it was quite a
> bit of fun to implement all that.)
>
> Outreachy sponsoring
>
> The goal is to support three interns in the round starting in early
> December, at $10,000 each. The corporate sponsorship previously provided
> by GitLab and GitHub has dried up, leaving Git itself to pay. There are
> company contacts to follow up with; Emily offered to ask Google's OSPO,
> without high expectations. No new sponsorship commitments were made.
> (Personal note: I don't think that these internships provide enough
> publicity to give companies much of an incentive to fund this. Which I
> find a bit of a shame, Outreachy in particular does a lot of important,
> good work, and if I wasn't so constantly overworked, I would want to
> mentor again; I always found it rewarding, even if I hold myself to a
> quite high bar which is quite draining.)
>
> A related point for Git Merge 2027: announcing the location early would
> help Outreachy and GSoC interns plan attendance. No location was selected.
>
> Pluggable object database
>
> Patrick's pluggable object database is working, but it is not complete:
> commit-graph and multi-pack-index integration are still outstanding, and a
> repository extension is planned. (Personal note: It might be interesting
> to see whether implementing a storage backend is easier in core Git or in
> another Git-compatible implementation. JGit should be a natural target,
> having originated within BigTable-sized constraints, i.e. a different
> storage system, but funding seems to have dried up, there's not even
> SHA-256 support, so JGit might not be as hackable as it once was.)
Pluggable backend implementations for JGit have been possible for quite some
time, although, admittedly, I don't think any made it to production. 
Maybe at
the time when this was introduced(16 years ago!!) by Shawn[1] in JGit it 
wasn't
fashionable yet and so the project was never carried forward. I know Luca
submitted a talk for the Gerrit User Summit to present a Cassandra 
back-end, for
which I can see conversation started 10 years ago[2].

Regarding JGit support's for SHA256, I know some corporations have had 
interest
in sponsoring this work and have discussed potentially implementing 
together it
with GerritForge, but, as far as I know, work isn't ongoing yet. JGit is 
still
very much developed and kept up to date with great effort from the 
community, so
I believe it to still be as hackable as it was, there just hasn't been 
enough
interest for SHA-256 yet, which I agree is a shame, hopefully in the 
near future
this gets remediated.

[1] https://github.com/spearce/jgit_cassandra
[2] https://groups.google.com/g/repo-discuss/c/IekVPmow0yE
>
> Content-defined chunking prompted an important distinction between
> changing how objects are stored and changing the logical object model.
> Starting at the storage layer would let us preserve existing blob OIDs
> rather than require ecosystem-wide changes. A new pack/index format could
> provide another representation of the same object, much as deltas do
> today. No particular representation was agreed. (Personal note: It is
> curious to me why nobody tought about inventing a "meta blob", i.e. an
> object much like a tree object, except that it stitches together a larger
> blob. This would allow for the content-defined chunking that `rsync`
> already championed, way before Git was born! It would have allowed a Git
> native large file support worth writing home about, and could have
> replaced Git LFS. Xet (https://huggingface.co/docs/hub/xet/index) would
> not have had to be invented, and it would have allowed game development to
> move to Git. I can only imagine that the time it would cost to get even
> the first patches of this into core Git would be seen as prohibitive by
> any company who may have considered the effort.)
>
> There is also an API question: does a backend seeing only object content
> have enough context to make good storage and delta choices, or should it
> receive richer information? More searchable tree storage and a Git "commit
> cloud" were other possibilities raised, not committed plans. (Personal
> note: At a previous GitMerge, Facebook presented their work, see e.g.
> https://github.com/facebook/sapling/blob/main/eden/mononoke/blobstore/packblob/README.md,
> which includes separating actual storage from transport. That is, already
> at push time, derived metadata is computed in async jobs which provide
> several potential deltas ready-to-go when a client clones or fetches. They
> reported clones with regular Git clients that are twice as fast, just
> because the server doesn't need to spend much compute on the data it
> sends. So there is a lot to be learned out there already.)
>
> AI
>
> The current SubmittingPatches policy is rooted in DCO certification and
> advice from SFC lawyers. The unresolved question is whether, and to what
> extent, contributors can certify AI-generated code. There was substantial
> disagreement about acceptable use, provenance and legal risks, community
> trust, review burden, and whether the current caution excludes useful
> tools. No policy change was agreed. (Personal note: You'd think that the
> opinion of lawyers is taken at face value, but no, it seems that some core
> Git contributors seem to disagree with the lawyers in favor of their own
> opinion...)
>
> Several participants found language and proofreading assistance useful. A
> particular concern was submissions where the human does little more than
> relay agent output, leaving reviewers to deal with the consequences. The
> influx of poor GSoC contributions was one example. Attribution such as
> Assisted-by was suggested to make tool use clearer, but attribution alone
> does not answer the quality or DCO questions. (Personal note: my precedent
> of "Assisted-by" was called out as helpful, and I do think it is. I make a
> difference between AI-generated and AI-assisted. I'm not a fast typer, so
> I benefit a lot from being able to tell an LLM to please refactor out
> these four lines with the appropriate signature. There's not much
> creativity in there. I also like to let AI present me the call graphs for
> certain code locations, because due to the choice of C, which thanks to
> the C preprocessor is not easy to analyze statically, there are no
> competent tools other than LLMs that I can use for the task. I was highly
> surprised, though, to see how much enmity against AI in general was
> voiced, not by many, but many, many times, and how that contrasts with the
> Linux project which I hitherto had not considered to be as particularly
> open to modern practices.)
>
> brian and Taylor agreed to put differing policy proposals on the list. The
> suggested process is to have alternatives examined by SFC counsel, make
> the risks clear, and then consider a vote. Emily volunteered to organize
> the voting procedure. Eligibility and the details remain open; Junio's
> authority as maintainer remains central. (Personal note: Since Taylor
> works for OpenAI now, I was not surprised by his stance, but brian works
> at GitHub, home of GitHub Copilot, and I am not sure how favorable their
> employer would look at their semi-public utterings about AI...)
>
> Protocol v2 for pushes
>
> There are concrete use cases now: repositories with millions of refs,
> including a reported 896 MB ref advertisement. Reftable improves ref
> update throughput, but does not by itself solve the advertisement problem.
> Nobody objected to push protocol v2, and the fetch-v2 infrastructure
> already provides much of the foundation.
>
> The discussion covered advertising fewer refs, letting clients identify
> useful branches, and replacing large advertisements with a few rounds of
> push negotiation. Negotiation results could also help optimize the
> server's connectivity checks. Some improvements might be possible in the
> existing protocol before introducing v2.
>
> We need to measure the tradeoffs rather than assume fewer bytes means
> faster pushes. One example involved a shallow push taking 35 seconds
> instead of two because of work to minimize the transfer. Shallow
> boundaries and unrelated histories complicate the proposed heuristics.
>
> SHA-256 interoperability is another reason to want push v2: the current
> push protocol requires using the server's primary hash algorithm.
> Negotiation could make that more flexible.
>
> Forge replication to thousands of mirrors would benefit from finding out
> cheaply whether refs have changed, rather than downloading full
> advertisements from every target. Checksums, ETag-like values, and
> reftable generation numbers were discussed, with concurrent updates
> complicating the picture.
>
> Compact or compressed advertisements are also worth exploring and
> benchmarking, possibly reusing reftable's format. That does not mean
> sending the server's actual reftable, including hidden refs. There are
> several promising directions here, but no final design yet.
>
> Some breakout sessions were planned, but apparently had to be cut.
>
> Personal notes: I wasn't present for all of the sessions, in the afternoon
> I had other commitments; Therefore these notes (which AI assisted me in
> distilling) came partially from what I dictated and partially from the
> shared Google Document in which a few volunteers gracefully wrote notes. I
> found it challenging to connect as a remote participant. The link to the
> Google Meet, as well as control over the lobby thereof, seems to have been
> restricted to at most a few people, which might have contributed to the
> long waiting time before I was allowed in, and it definitely contributed
> to my comments not reaching the discussion in time to have an impact. I
> would have loved for Junio or the other two brave souls who also
> participated remotedly to have had more "air time". I am still a fan of
> the idea to have more frequent, smaller, virtual Contributor Summits,
> organized by a rotating cast. (Maybe I can get Emily to host the next
> one.) I was very happy that Junio was participating, as he _is_ the
> project lead, and in past Contributor Summits decisions were taken without
> him, which I found odd. Timing was really challenging for him, though, it
> was way past midnight for him. I'm all the more grateful that he
> did participate.
>
> Final remark: This summary is obviously biased. I lightly edited it to
> separate better between my personal views and a hopefully unbiased account
> of what was discussed, and how, and by who. Nevertheless, I am but human.
> As a consequence, I would be delighted if other participants would share
> their summaries, so that my bias can be balanced out.
>
> Ciao,
> Johannes